bug#64827: texlive is broken

[Nicolas Goaziou]

Hello,

I'm sorry as I have limited time and bandwidth right now to help you
solve this issue. It doesn't seem too bad, tho.

Andreas Enge <andreas@enge.fr> writes:

> Actually the roots of this go back a very long time!
>
> commit dfdc002c9bf86270941823a96abded0aa5d44088
> Author: Ricardo Wurmus <rekado@elephly.net>
> Date:   Mon Jul 15 19:07:40 2019 +0200
>     gnu: texlive-bin: Include scripts.
>     * gnu/packages/tex.scm (texlive-bin)[inputs]: Add texlive-scripts.
>     [arguments]: Let fmtutil.pl reference scripts directory.
>
> This commit includes into texlive-bin files not taken from the tarball,
> but downloaded via subversion. This is only needed for the modular texlive,
> I suppose, since in the monolithic one these files will be taken from
> texlive-texmf. However, this has been working nevertheless for a long time.
>
> Then there is
> commit 04a0b1e09abce99857e7930336421ca6d15ae630 (HEAD)
> Author: Maxim Cournoyer <maxim.cournoyer@gmail.com>
> Date:   Mon Jan 11 11:08:15 2021 -0500
>     gnu: texlive-bin: Enable the use of multiple TeX Live trees.
>     Attempting to compose multiple TeX Live trees (such as can happen when 
> using a
>     texlive-union generated package) proved problematic; only the texmf.cnf
>     configuration file from the union would be honored, causing other TeX Live
>     components to be ignored.
>     This change does away with TeX Live unions, instead relying on the default
>     texmf.cnf configuration file provided by the texlive-bin package to honor
>     individual TeX Live trees referred to via the newly introduced GUIX_TEXMF
>     variable, and replacing the texlive-union procedure by 
> texlive-updmap.cfg, to
>     explicit that generating the fonts map configuration is now its sole 
> purpose.
>
> This introduces the GUIX_TEXMF environment variable, and the commit is
> clearly only useful for the modular texlive.
>
>
> Going back to commit 9fadbf759c7ae0c4555bf43883f3f0a0d8a4e6a6 is not
> enough to get "guix shell -D texlive".

I think this may be fixed by tweaking `texlive-font-maps' function in
"profiles.scm". This function should only be used for modular TeX Live,
and the criteria used for it is very gross: it checks the presence of
a "texlive-" prefixed package among the entries.

Unfortunately, when using "guix shell -D texlive", `texlive-libkpathsea'
is among the entries, and `texlive-font-maps' is activated.

> Going back to commit ad457d01147b8d6fcb4ee64b2dc2d699caa1d1ee of July 17
> (this one happens to be a day I did a "guix pull") works for "guix shell".
> I do not quite understand why - here also both packages have collisions
> in the script files as above.

Collisions are harmless. It is possible to avoid them, but a bit
tedious.

> Given how much the current texlive-bin and texlive-kpathsea and thus
> probably the derived texlive-bin-full cater to the needs of modular
> texlive, I wonder whether for a monolithic package it would not be easier
> to start from scratch on a clean slate, using modern source and an
> old package recipe.

I don't think you can do away with the dichotomy between
`texlive-bin-full' (previously texlive-bin) and `texlive-texmf'. The
former is used to build the executables and the latter contains
everything else. I don't think there exists a way to merge these two
steps into one.

> Now the question is whether we still want a monolithic package in the
> distribution. Historically it is there because it was the easiest to
> package. But I must say that while I find it a bit painful to install
> (all these gigabytes of data to copy!), I have also come to find it
> tremendously useful. All of texlive with me all the time! So I am quite
> certain I would want to maintain it.

Note that modular `texlive-scheme-full' (not yet packaged!) would be
equivalent to monolithic `texlive'. At some point, we may be able to
drop `texlive' (and `texlive-bin-full'). Even if we do not hit 100%
coverage (who really needs that?), it is still possible to install
a complete TeX Live system using the genuine TeX Live installer.

Meanwhile, fixing `texlive' should not be too hard, and monolithic and
modular TeX Live are still pretty much independent from each other.
n
In particular, `texlive-libkpathsea' is not indispensable for
`texlive-bin-full'; it was introduced, along with inheritance from
`texlive-bin', to reduce code duplication. IOW, it should possible to
partly revert 19fd1004138b60c4479d7516aa0cee261c0b6b57 — i.e., make
`texlive-bin-full' a copy of previous `texlive-bin', barring the update,
and some related fixes such as disabling parallel tests — should fix
monolithic's issue.

Would you have some time to try it?

Regards,
-- 
Nicolas Goaziou