Re: Adding kerTeX; but needs avoiding configure etc.

[Brook Milligan <brook%nmsu.edu@localhost>]

> On Aug 25, 2019, at 8:30 AM, tlaronde%polynum.com@localhost wrote:
> 
> On Sun, Aug 25, 2019 at 07:55:37AM -0600, Brook Milligan wrote:
>> 
>>> On Aug 24, 2019, at 6:30 AM, Greg Troxel <gdt%lexort.com@localhost> wrote:
>>> 
>>> tlaronde%polynum.com@localhost writes:
>>> 
>>> BTW, since there is a TeXlive discussion going on, kerTeX solves
>>> the problem at a different level: kerTeX is a hosted system; TeX
>>> related packages are its problem not the problem of the host. There
>>> is a packaging system for kerTeX allowing to add LaTeX and etc. to
>>> the core, "kernel" system (hence the name with a word play between
>>> ker(nel) and "care"). So there is only one (in fact two for
>>> cross-compilation) package for TeX the additions being handled by the
>>> TeX hosted system.
>>> 
>>> This is not the pkgsrc way
>> 
>> More strongly, not only is this not the pkgsrc way, but mixing the kerTeX packaging system with pkgsrc as a user interface is a major step backward.
> 
> There is no mixing. It is totally independent. Totally orthogonal. And
> you speak about the ease of updating and administration. But this is
> what kerTeX does offer: cross-compilation; unprivileged install and,
> furthermore, exactly the same user interface for administration of
> packages on whatever machine and whatever OS.

The same is true for most (all?) other domain-specific packaging systems.  For example, pip purports the same.  So does the R install.package() function.  That is fine and very useful.

However, once one starts relying on those (or a mix of those + pkgsrc) as the user interface for managing software, the benefits of a single means of managing software across different systems each usually with unique suites of software is lost.  There are situations where that is a huge problem and therefore using other packaging systems, even in a mix with pkgsrc, is not helpful and is a step backwards.  Each step in that direction returns us bit by bit to the source of inspiration for pkgsrc in the first place, an urgent need to tame the myriad complexity of software installation systems.

It sounds like kerTeX already has all the pieces needed to support any package on any machine.  That is super and makes packaging all the easier; thank you for that.  As you design the mk infrastructure, just standardize what a pkgsrc package would look like in order to use that pre-existing capability.  Given the simplicity of TeXlive packages and your description of the generality of kerTeX, I am not seeing this as a huge task; however, if it is more complex than I am seeing I am sure people here would be willing to help.  Use that infrastructure in whatever kerTeX packages initially make sense in pkgsrc.  No doubt that will not be "all TeX packages", just as "all TeXlive packages" do not exist in pkgsrc.  However, if the infrastructure is in place and all kerTeX pkgsrc packages are standardized, as for example TeXlive packages are, then anyone who needs to add one can do so easily.  A tool could also be written to do the same, much as texlive2pkg does now.  There is no need for combinatorial explosion here, but there is a need for a pathway that makes it possible to manage software using a single user interface.  You need not maintain or develop wrappers for thousands of kerTeX packages; that makes no sense.  It would be very helpful, however, to develop a standardized pathway so that the pkgsrc community can add and maintain whatever packages do make sense.

Cheers,
Brook