Re: Adding kerTeX; but needs avoiding configure etc.

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

> On Aug 25, 2019, at 11:19 AM, tlaronde%polynum.com@localhost wrote:
> 
> 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.

Sorry if I am not being clear.

I feel that the issue is "kertex added package" versus "pkgsrc added package".  Here I take "added" to mean "installed using a command provided by kertex versus by pkgsrc".  In that sense, having "kertex added packages" at all is the step backward in my mind, because that subverts the unifying capacity of pkgsrc.  If a pkgsrc package uses kertex to install things, that is a great leverage of kertex's capability because the pkgsrc bits will be simple and easily standardized.  But, the user-facing installation should be through the pkgsrc mechanism so that its strengths can be leveraged also.

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

No, the pkgsrc DB is not necessarily owned by root.  It is if installed "normally" by root.  However, unprivileged installs have been well supported by the bootstrap process for a long time, even on NetBSD.  In that case, the pkgsrc DB is owned by whoever bootstrapped pkgsrc.  I do this all the time, even on systems I have root access to.  For example, it is possible to have one installation in my home directory (or anywhere I choose) that I use in production and another somewhere else that I use for development.  Two different bootstraps, two different sets of packages, possibly two different corresponding pkgsrc trees, no problem; just make sure that the path includes the appropriate one.

This is super important (not just to me, but to the potential use of pkgsrc on a wide array of systems), because it allows one to customize his/her software environment on _any_ system, even without root access, using a single user interface, i.e., pkgsrc.  I find having to do this all the time on, for example, supercomputing systems, that never seem to have the right collection of software available; using pkgsrc instead of all the different foreign methods is a lifesaver.  This is a strength of pkgsrc; any step away that power seems backward to me.

> 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[*] ).

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

Thus, do not change kerTeX or its ability to work smoothly everywhere.  Simply leverage that capacity to standardize how a certain group of pkgsrc packages, those that involve kertex, can be made.  Just make the common infrastructure that wraps the kertex bits within pkgsrc, and then make enough kertex packages to get things started.  If people want more, you have empowered them to easily make more.  In the process, we have retained pkgsrc's dominant strength: the ability of one user interface to automate all software management everywhere.  I do not wish to retreat from that.

Cheers,
Brook