bug#64827: texlive is broken

[Andreas Enge <andreas@enge.fr>]

Am Wed, Jul 26, 2023 at 11:21:23PM +0200 schrieb Andreas Enge:
> still does not work any more. It prints
>    building TeX Live font maps...
> (which looks like something a monolithic texlive should not do),
> and it shows conflicts such as between
>   /gnu/store/y72v93b7f12nx8xq0ljwlzj9yn5b07vk-texlive-bin-20230313/share/texmf-dist/scripts/chktex/deweb.pl
>   /gnu/store/l8g23z46mpzzbq7isnjk65vcx47i2cgf-texlive-texmf-20230313/share/texmf-dist/scripts/chktex/deweb.pl

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

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.

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.

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.

Andreas