Hello,
Am Tue, Jul 25, 2023 at 12:09:06AM +0200 schrieb Ricardo Wurmus:
> > I can't find the format file `pdflatex.fmt'!
> This sounds like a sibling of https://issues.guix.gnu.org/64729
it looks similar indeed. But notice that I use the monolithic package
"texlive".
And I just tried it again and - it just works! In the meantime, I have
rebooted. And while I thought I had done it, I must have forgotten to
include $GUIX_PROFILE/etc/profile for updating environment variables.
However, it has become extremely slow. When compiling a 42 page document:
real 0m22,757s
user 0m7,243s
sys 0m15,370s
Before it even outputs the first page of the document, I get pages and
pages of screen output looking like lisp code:
(/home/enge/.guix-profile/share/texmf-dist/tex/latex/amsmath/amstext.sty
(/home/enge/.guix-profile/share/texmf-dist/tex/latex/amsmath/amsgen.sty))
(/home/enge/.guix-profile/share/texmf-dist/tex/latex/amsmath/amsbsy.sty)
(/home/enge/.guix-profile/share/texmf-dist/tex/latex/amsmath/amsopn.sty)) ...
This is compared to before:
real 0m1,426s
user 0m1,191s
sys 0m0,113s
Where the lisp style lines look like this:
(/gnu/store/m2hpk7ycdqj6n1nbjnd3d4l088m79smx-texlive-texmf-20210325/share/texmf
-dist/tex/latex/amsmath/amstext.sty
(/gnu/store/m2hpk7ycdqj6n1nbjnd3d4l088m79smx-texlive-texmf-20210325/share/texmf
-dist/tex/latex/amsmath/amsgen.sty))
The difference is that before, /home/enge/.guix-profile/share/texmf-dist
was directly a symbolic link into the store. Now it is a directory, and
each file in it is its own symbolic link to a file in the store, and
resolving them apparently takes a lot of time.
I am confused as to why this happens.
/home/enge/.guix-profile/share/texmf-dist contains 28 symbolic links,
26 of which point to directories and 2 to files (ls-R and README) in
/gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/
Then there is the "physical" directory web2c. It contains 47 separate
symbolic links to files and directories in
/gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/web2c.
I do not understand why not the complete texmf-dist is a symbolic link
as before, as the content seems to be the same, which should be handled
during the profile creation.
Maybe because of this in the definition of the texlive package:
;; Build the union of texlive-bin-full and texlive-texmf, but take the
;; conflicting subdirectory share/texmf-dist from texlive-texmf.
What is the role of texlive-bin-full? Why does it contain share/texmf-dist?
The basic architecture was to separate the binaries in texlive-bin (which
needed compilation) from the tex files in texlive-texmf (which mainly needed
copying, plus the black tex magic of format and font map creation), and
their union was texlive.
My impression is that
commit 19fd1004138b60c4479d7516aa0cee261c0b6b57
Author: Nicolas Goaziou <m...@nicolasgoaziou.fr>
Date: Mon Jun 26 12:00:51 2023 +0200
gnu: Externalize libkpathsea in texlive and texlive-bin.
poses problems. Which problem is it supposed to solve?
What is the idea of the new architecture? Having texlive-libkpathsea,
texlive-bin and texlive-bin-full, all the three with very long package
definitions, looks very complex to me.
Would it be possible and make sense to revert this commit?
I considered opening a new bug, since this one looked distinct from
not being able to install texlive-biber; but I wonder if texlive-biber
is not simply a symptom of the same problem.
The error message is
updmap: open() failed: No such file or directory at
/gnu/store/rhaj62vg3bfzlvrm9bsmif4z1bzgq84a-texlive-scripts-66594/bin/updmap
line 2159.
updmap [ERROR]: The following map file(s) couldn't be found:
updmap [ERROR]: dvips35.map (in builtin)
updmap [ERROR]: pdftex35.map (in builtin)
updmap [ERROR]: ps2pk35.map (in builtin)
updmap [ERROR]: Did you run mktexlsr?
Notice the location of the updmap script. The one in my profile points to
/gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/bin/updmap
of the texlive package and the missing .map files are there at
/gnu/store/88apcyl30irw6v03gmyav638wq31k9xq-texlive-20230313/share/texmf-dist/fonts/map/dvips/tetex/dvips35.mapand
so on.
So my impression is that the new way of packaging breaks the monolithic
texlive package, and that the texlive-biber package by using the
texlive-build-system has become incompatible with the monolithic texlive.
This comes from commit
commit 3aeca58073eff8b7a835f6492e735dd152d9dc99
Author: Nicolas Goaziou <m...@nicolasgoaziou.fr>
Date: Mon Jun 19 14:43:56 2023 +0200
gnu: biber -> texlive-biber.
which moves from perl-build-system to texlive-build-system.
Andreas
