Re: Adding kerTeX; but needs avoiding configure etc.

[tlaronde%polynum.com@localhost]

On Sun, Aug 25, 2019 at 10:03:48AM -0600, Brook Milligan wrote:
> 
> > 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.

I still fail to see where the problem is but IMO all there will be to
add is a kertex_pkg "pkgsrc" package that will simply put an entry
in pkgsrc db for every kertex added package, the option to the pkgsrc
kertex_pkg being the name of the package to add.

But doing it this way, one looses for example the unprivileged install
of kerTeX: it can be installed anywhere under whatever user. The pkgsrc
db is owned by root.

I'm mainly a NetBSD user but kerTeX is not designed specifically for
NetBSD. It is designed to give TeX and al. to whoever wants it on
whatever machine/OS one uses. A user doesn't use NetBSD' kerTeX: he uses
kerTeX ON NetBSD that behaves the same as kerTeX ON whatever else (even
on Windows, it is the same; there is no need for special versions or
special User' Guide; the utilities are the same; the addition of
packages too). The same goes for Perl, Python and whatever.

These are significative huge software packages so that one claiming being
a user has to know how to use it. But once the user knows, it will be
the same under whatever host OS it runs.

So my opinion is that for other huge beasts (kerTeX is not huge in
size; but it is huge when one considers all that can be added as macros
or fonts on it), the solution would be to have a mean to install the
core on the OS (here, pkgsrc) and to let packages being delt with by
whatever commands the package provides, keeping the namespace clean (if
one adds Perl, the Perl binaries path has to be added to the PATH by the
user; and additions go in this dedicated subdirectory not cluttering the
"root" /usr/pkg/bin/ or /usr/pkg/sbin/ directories[*] ).

The up-to-date being then only an upstream problem.

* : there is amongst a lot of good things, something Plan9 provides that I wonder why sh(1)
has not added: the ability to call an utility with a subdir prefix: ip/*
for ip related utilities etc. To be able to call: perl/*, kertex/*,
python/* etc and to be able to have completion on subdirs would be a
great bonus, without a lot of work, and would help to have a clean
hierarchy and a consistent namespace.
-- 
        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