Re: Adding kerTeX; but needs avoiding configure etc.

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

> 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.

One of the big advantages of pkgsrc in my mind is the ease with which updates and bulk deployments on new systems can be handled.  As one example, an entire suite of machines can be described in a single pkgchk.conf file and pkg_chk can update (as needed) all of them.  Even for a single machine it is easier to make a list of desired packages and run pkg_chk on it than to do it manually.  As another example, pkg_rolling-replace can manage updating a complex collection of packages.  If users are expected to install a kerTeX package and then use its packaging system to manage the packages, all of that is lost for any kerTeX packages installed with its own packaging system.  _Please_ do not do this.

A much better approach would be to make it really easy to build (and update) pkgsrc packages from kerTeX packages.  Presumably all kerTeX packages would have a canonical form that can be captured in some portion of the mk infrastructure.  R packages already do this, for example; each one sets a small number of standardized make variables and includes Makefile.common from math/R which makes use of R's unique internal installation system.  A simple tool could take a kerTeX package and generate (or update) the canonical pkgsrc version.  R2pkg demonstrates that this is possible for R packages, so something analogous should easily work for kerTeX, especially because the underlying mk infrastructure can take advantage of the kerTeX packaging system to do the dirty work.

It would be great to have kerTeX in pkgsrc, but please do not subvert the value of pkgsrc as a single user interface for managing complex suites of packages across multiple machines.  Keep the user interface consistent so that all packages are managed with pkgsrc tools.  Maybe that is what you meant all along, but it did not sound that way from the paragraph above.

Thanks for thinking about the value of adding kerTeX.  Done right it would be wonderful to have.

Cheers,
Brook