all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Josselin Poiret <dev@jpoiret.xyz>
To: Emmanuel Beffara <manu@beffara.org>, help-guix@gnu.org
Cc: 56556@debbugs.gnu.org
Subject: Re: bug#56556: TeXlive packaging issues
Date: Wed, 29 Mar 2023 20:48:30 +0200	[thread overview]
Message-ID: <87o7obs8ap.fsf@jpoiret.xyz> (raw)
In-Reply-To: <20230328213044.GB4873@beffara.org>

[-- Attachment #1: Type: text/plain, Size: 3642 bytes --]

Hi Emmanuel,

Emmanuel Beffara <manu@beffara.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 682 bytes --]

  reply	other threads:[~2023-03-29 18:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-28 19:30 TeXlive packaging issues Emmanuel Beffara
2023-03-29 18:48 ` Josselin Poiret [this message]
2023-04-07 10:33   ` bug#56556: texlive-babel-dutch with and without texlive-hyphen-dutch: No hyphenation patterns were preloaded Ludovic Courtès
2023-04-07 10:47     ` Emmanuel Beffara
2023-05-19 15:22       ` Simon Tournier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o7obs8ap.fsf@jpoiret.xyz \
    --to=dev@jpoiret.xyz \
    --cc=56556@debbugs.gnu.org \
    --cc=help-guix@gnu.org \
    --cc=manu@beffara.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.