Re: Adding kerTeX; but needs avoiding configure etc.

[tlaronde%polynum.com@localhost]

On Sun, Aug 25, 2019 at 12:33:15PM -0600, Brook Milligan wrote:
> 
> Please no.  This takes us back to the days when every collection of software had to be handled individually.  That was a mess and still is everywhere it is still required.
> 
> Let me follow your suggestion just a bit.  Suppose I could install a kertex core package using pkgsrc and then had to use the kertex tools to install other parts; I think that is what you are suggesting, right?  So, I go through that process and customize the kertex I want.  Now suppose I have a new system.  On it, I can install the core kertex package really easily and automatically, because it is embedded somewhere within my list of 500 pkgsrc packages that I need; no problem.  However, to get the kertex customization I need, I next have to manually go through whatever process I did before using the kertex tools.  Even if all the commands are the same, this is needless tedium and a cognitive burden; it is a barrier that we need fewer not more of.  Now multiply this by N systems.  Now update it all on N systems.  Now imagine the parallel case for Perl packages.  I install my core Perl package easily using pkgsrc, but do this dance again on N systems for all the perl packages I have to add using Perl's install tools.  Now add Python, R, ... .  Now jump off a cliff.  This does not scale.  Indeed, this is the very world that pkgsrc is trying to avoid by going to the trouble of wrapping all sorts of case-specific installation processes behind a common interface.  I contend that we do not want to lose that by exposing case-specific installation processes again, even if they work "everywhere".
> 

Where do you see that this means "adding by hand"? This can be scripted
and the _same_ script will run on whatever installation, on whatever
machine, on whatever OS.

Even when I install a NetBSD, I have to customize. One can install
pkgsrc packages and customize even these packages (you do not config
packages to that last bit with pkgsrc).

The first reason of the packaging systems in the Unix like system is
simply to allow to install software that comes only as sources with no
binary version for the system. To be able to compile for the system and
to share the burden.  When one finds the way to compile for the
system---and this may need some knowledge that the end user, not
programmer, has not---others have not to find by themselves and can
benefit from the efforts made by one.

The packages "administration" is a consequence; a side effect; not the
aim. This is the red tape that has to be kept to the strict minimum.
Once the red tape takes more time than compiling by hand, there is a
huge problem.

And you fail to see the point: there are a myriad of TeX packages
meaning there would be a myriad of pkgsrc kertex packages to add. I had
already the necessity to create packages for kerTeX because the majority
of users are users of TeX but don't know how it works. I will not have
the obligation to create N * myriad packages for N different packaging
systems for absolutely no reason at all. If I have created a packaging
system for kerTeX this is precisely to avoid this. The aim is to be able
to use TeX and al. and not to spend time---indeed: my time---creating
packages.

If others voice too that it shall be all or nothing: add a pkgsrc version of
everything or don't add a pkgsrc kerTeX installation, my engineering
decision is already taken: there will be nothing. kerTeX has no problem
installing on NetBSD the same as for any other system. It doesn't need
pkgsrc. A pkgsrc install version is just a convenience for users as long as
it is not a major inconvenience for me.

So the question for other pkgsrc maintainers/developers is this: all or
nothing, or just the core kerTeX and that's it? The answers, I have
already given: it will be nothing xor just kerTeX.

So please others give your point of view.
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C