Subject: bug#64827: Texlive-biber not installable

From: Andreas Enge <[email-masked]>
Date: Wed, 26 Jul 2023 18:33:51 +0200

Hello!

Am Wed, Jul 26, 2023 at 05:25:59PM +0200 schrieb Nicolas Goaziou:
> This should still be the same. The main difference is that `texlive-bin'
> was renamed `texlive-bin-full'. Any other change was probably not intended.

Okay, I understand. It looks like there was another change, but I do not
see what it was...

> I think the issue here may be that you are conflating the two TeX Live
> systems currently provided by Guix, i.e., you both install `texlive' and
> some "texlive-" package.

Okay. In my profile, I only have texlive and biber.

Since biber is deprecated by texlive-biber, updating the profile leads to
texlive and texlive-biber being there, which causes this conflict.
I think the solution will simply be to reinstate the previous biber
package to go with the monolithic texlive and keep it next to texlive-biber.

> Coming from modular TeX Live, `texlive-biber' is certainly incompatible
> with monolithic TeX Live, which, being monolithic, is expected to
> include "biber" executable anyway.

No, biber was not part of the monolithic texlive. Probably because it is
an additional binary which is not part of texlive-bin. Or maybe it was not
part of the texlive distribution in the past? We used to download it
separately from CPAN. Re-adding the biber package will be an easy fix,
I think; indeed maybe it should be added by default to the monolithic
texlive, assuming that its source code is part of the texlive distribution.
Apart from that, I have no strong opinion either way.

> Monolithic TeX Live is (and always was) unrelated to profiles.

Well, these symlinks to files or directories in the store are created
when the profile is put together. And for efficiency, the links are
to the highest level directory that is not merged from two different
packages. So what is linked depends on what is in the profile, and
for instance splitting a package in two can lead to files being linked
rather than directories. But this does not seem to be the case here,
I do not quite understand yet what is happening.

> You seem to have some clues about the slowness; you reported there are
> too many symlinks in monolithic TeX Live. This is not intended and
> should be fixed.

Clues, yes, but not a full understanding yet.

Thanks for the explanations,

Andreas