Subject: Re: bug#56556: TeXlive packaging issues

From: Josselin Poiret <[email-masked]>
Date: Wed, 29 Mar 2023 20:48:30 +0200

Hi Emmanuel,

Emmanuel Beffara <[email-masked]> writes:

> Firstly, unless I am missing something, creating a manifest with the right set
> of packages is tedious: one has to guess the Guix package that matches each
> LaTeX package, and the correspondence is not obvious. Thankfully, with a
> working installation, `tlmgr show something.sty` helps finding the TeXlive
> package that contains the file and `guix search texlive something` finds the
> corresponding Guix package if there is one (it could be named
> `texlive-something` or `texlive-latex-something`, this feels somewhat
> inconsistent). When trying to compile a complex document, doing that for every
> package and dependency is time-consuming (compile, read compilation errors,
> install more packages, restart).

I agree, although this is because the tex packages aren't super well
packaged.  A lot of dependencies aren't actually included, meaning you
need to add them manually.  This could be improved by just fixing those
package definitions to include them, I actually have some comments about
this in my TODOs.

> Secondly, many packages are missing. Apparently, `(gnu packages tex)` contains
> an arbitrary set of common packages, likely defined by people who needed them
> and had the skill to produce a patch for them. It is fairly easy to produce
> new definitions using `guix import texlive something` and adjusting the
> result, still it feels more complicated than it ought to be. Considering how
> well TeXlive is organized, it should be possible to automatically extract the
> set of all packages in a given release and turn the result into a big
> comprehensive Guile module.

Actually, no, for 2 reasons: as you said, you often need to adjust the
result of the import, and some of them need to be individually
inspected.  Also, upstream doesn't report what inter-package
dependencies there are (AFAIK).  This prevents us from generating the
right packages (see above).

> Besides, importing TeXlive "collections" could be a useful intermediate
> between taking the whole system and picking packages individually.
>
> Thirdly, formats are apparently not handled right. The main issue is with
> hyphenation (hence the cc on an open issue): hyphenation patterns need to be
> compiled into the formats to be available in documents, so the format files
> should be built depending on which `texlive-hyphen-something` packages are
> installed. Currently this is not the case:
>
> ```
> $ guix shell --pure coreutils texlive-base texlive-latex-base -- /bin/sh -c 'realpath $GUIX_TEXMF/web2c/pdflatex.fmt'
> /gnu/store/m1vh5mm4gjlqzaylfxmxbx5g3j20k8wn-texlive-latex-base-59745/share/texmf-dist/web2c/pdflatex.fmt
> $ guix shell --pure coreutils texlive-base texlive-latex-base texlive-hyphen-base texlive-hyphen-french -- /bin/sh -c 'realpath $GUIX_TEXMF/web2c/pdflatex.fmt'
> /gnu/store/m1vh5mm4gjlqzaylfxmxbx5g3j20k8wn-texlive-latex-base-59745/share/texmf-dist/web2c/pdflatex.fmt
> ```
>
> If the format is always the same, then no modular installation can do any
> hyphenation, as reported in https://issues.guix.gnu.org/56556. There might be
> other things than hyphenation that require similar treatment.

I don't really know how we could fix this: maybe build the formats with
all the hyphenation packages enabled?

> That said, I don't know what would be the best way to contribute.

I think fixing step by step all the packages you find to be deficient is
already a good first step.  I've been planning to do that as well but
got swept up in other things.

HTH!

Best,
-- 
Josselin Poiret