Re: texlive organization on netbsd

["Ian D. Leroux" <idleroux%fastmail.fm@localhost>]

On Wed, 13 Jun 2018, at 07:31, Mayuresh wrote:
> On Wed, Jun 13, 2018 at 11:51:48AM +0100, Jonathan Perkin wrote:
> > * On 2018-06-13 at 03:37 BST, Mayuresh wrote:
> >
> > > nodejs : more than 350000 packages [1]
> >
> > Nobody should be proposing that we start packaging NPM packages,
>
> All of them may have several differences. But one similarity between
> the examples I gave is the insanely large package count - compelling
> enough to rethink the compulsion of pkgsrc-only model.

There's nothing special about large "package" counts, not when your
definition of "package" is broad enough to include any downloadable bit
of software with no meaningful curation, dependency-tracking, or other
metadata.  Providing "all of python" or "all of TeX" is not much
different, and not much more interesting, than providing all the .c
files on the internet.  It just looks a little easier because someone
has already drawn up the list.  If an individual piece of software is
useful and used, we can make a package for it (and for some common
development platforms we are fortunate that there are tools to speed up
the process).  If it is not useful, then its absence from pkgsrc is not
a problem.  So the real question is, how much *useful* software is
there in those huge registries, and are people interested in packaging
it for pkgsrc?

You can, of course, argue that pkgsrc doesn't have the resources to
package all the interesting, useful software that's out there.  In the
short term this is probably true (and entirely independent of
programming language).  But the value of pkgsrc comes in large part from
the guarantees it tries to provide about the software in LOCALBASE
(dependencies are installed, versions are consistent, [partial]
isolation from the host environment's libraries, etc.), and those
guarantees come from the work of the packagers.  You can ease and
automate parts of that work, but you can't magic away the fact that
pkgsrc can only offer those guarantees for software that it knows about.

The user is always free to download, [build,] and install whatever they
like and take responsibility for the result.  I do that when I want to
play around with something exotic.  If the user-installed software lives
outside LOCALBASE tree and nothing in LOCALBASE depends on it, then it
is not pkgsrc's problem.  But if you want all the benefits of pkgsrc to
apply to a piece of software (and especially if anything else in pkgsrc
is going to depend on it), then someone is going to have to do the
requisite work to turn an entry in a registry into an actual package
worthy of the name.  I'm grateful that people have done that work for a
bunch of software that I find useful, some of which happens to be
written in python or in TeX.

-- IDL