Subject: [bug#53613] [PATCH] guix: Restore profile hook for TeX Live font maps.

From: Ricardo Wurmus <[email-masked]>
Date: Tue, 01 Feb 2022 00:08:02 +0100

Ludovic Courtès <[email-masked]> writes:

> Ricardo Wurmus <[email-masked]> skribis:
>
>> * gnu/packages/tex.scm (texlive-default-updmap.cfg): New variable.
>> * guix/profiles.scm (texlive-configuration): Rename this...
>> (texlive-font-maps): ...to this; update to run updmap-sys on the contents of
>> the profile to generate only font maps.
>> (%default-profile-hooks): Add texlive-font-maps.
>> * guix/status.scm (hook-message): Rename unused texlive-configuration to
>> texlive-font-maps.
>
> Out of curiosity, what does it fix, and how does it relate to past
> changes in this area (looks like ‘texlive-configuration’ was added, then
> removed, then reintroduced)?
>
> I’m asking for documentation purposes because I trust your judgment
> anyway.  :-)

The profile hook was called “texlive-configuration” because it would
create a customized texmf.cnf, the main configuration file for the whole
TeX Live tree.

Back then I saw no other way to support a modular TeX Live tree than to
operate on the texlive-* packages that have actually been installed in
the profile, build a union directory (hence the procedure name
“texlive-union”, which did the same thing but for packages), and then
install a texmf.cnf file that declared the prefix of the TeX Live tree
to be the union directory.

This was what the “texlive-configuration” hook primarily accomplished:
build the union, patch and install texmf.cnf.  It then proceeded to
operate on that union directory and generated font maps based on the
fonts that had actually been installed.

This approach had multiple disadvantages, the worst of which was that
you could only really have one TeX Live tree.  Maxim addressed this in
commit 04a0b1e09abce99857e7930336421ca6d15ae630, where texmf.cnf was
modified *once* and for all in texlive-bin to reference the GUIX_TEXMF
variable to determine the root of the tree.  This made much of
“texlive-configuration” (and “texlive-union”) obsolete, because we
didn’t need to have any union directories at all, because we had no need
for a customized per-profile variant of texmf.cnf.

Unfortunately, this change threw out the font-map-sized baby with the
texmf.cnf-infested bath water.  The effect of that was barely noticeable
because font maps are weird and aren’t always used.  Besides, we had a
couple of other font-related problems (e.g. invalid assumptions about
directory links in kpathsea), which masked this newly introduced
problem.

This patch pulls the baby out of the drain: we’re again generating font
maps (such as pdftex.map) based on the contents of the profile.

An alternative would be to install fully featured static font maps,
which would almost always be completely wrong, because they would refer
to fonts that haven’t been installed.  The profile hook ensures a) that
the expected font map files exist and b) that they contain nothing
beyond valid entries that correspond to the profile contents.

Does this really solve problems?  I don’t know.  I think it’s the right
thing to do (and thus makes our modular TeX Live less wrong), but it
didn’t solve mysteries like that koma-script bug that seems to be
related to a missing font map file.  The koma-script bug remains because
the font map file is ignored.

So … there’s more to fixing everything that’s wrong with fonts in our
modular TeX Live, but we’ve been chipping at it with commits like
4d2c861dfbd49f0e1619fda5dbf18e4cb5bca1d0,
2a5ed25c412e162505b2b371d00987fd158a91d4, and the like — this is
another one of these small things that should get us closer to the
platonic ideal of fonts with TeX Live.  I hope.

-- 
Ricardo