bug#64827: texlive is broken

[Andreas Enge <andreas@enge.fr>]

Hello,

Am Thu, Jul 27, 2023 at 11:55:01AM +0200 schrieb Nicolas Goaziou:
> 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.

no problem, this is also my last day before vacations.

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

Well, I also just saw this and solved it by calling the packages
"texlivebin" and "texlivetexmf" without a dash... Primitive, but
working.

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

No, I agree. But I think the current texlive-bin-full inherits lots of
things needed only for the modular system. Thus my suggestion to start
it from scratch again without inheritance.

> Meanwhile, fixing `texlive' should not be too hard, and monolithic and
> modular TeX Live are still pretty much independent from each other.
> 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?

Yes, I am on it!

The first commit is in the branch
   wip-texlive-mono
It drops everything monolithic from tex.scm, un-deprecates biber there,
and essentially reinstates commit ad457d01147b8d6fcb4ee64b2dc2d699caa1d1ee
in a new file texlive.scm, including the biber package.

In particular, it reverts the monolithic package back to 2021.

I have tested it by compiling my current favourite latex file (very fast
again) and "guix shell -C --pure -D texlive" (which works due to the dirty
trick above). I have not tested biber, which I normally do not need and
do not even know how it works (I happened to just have to use it blindly
in a project with other people through a Makefile or latexmk or so).

The next step I would like to try is to simplify the package by dropping
things introduced for the modular system. And eventually update it to 2023.
But given that each run easily takes an hour (unfortunately texlivetexmf
suffers from a graft, which takes a long time to go through more than 3GB!),
this can take a while. Definitely longer than today. But since we seem to
be on the same page and your suggestion above corresponds to what I had
already started on my side, the work will not be for nothing, and I am
motivated to hopefully finish it over the summer.

All the best,

Andreas

PS: While trying to push I noticed that there is a branch wip-texlive
    from January 2022; I suppose this can be deleted now?