[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question about packaging TexLive
From: |
Nicolas Goaziou |
Subject: |
Re: Question about packaging TexLive |
Date: |
Wed, 19 Apr 2023 13:47:16 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Ricardo Wurmus <rekado@elephly.net> writes:
> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> 1. "#:trivial? #t" means we're giving up generating ".sty" files from
>> source;
>
> Trivial should only ever be used for packages where there aren’t any
> sources to build from.
We are on the same length.
However, some packages do use "#:trivial #t" even though they should
not, e.g., `texlive-latex-marginfix'. My point is that we should not
make "#:trivial #t" the default, assuming that was a possibility
stemming from Simon's question.
>> 2. Some affected packages are also missing propagated inputs (e.g.,
>> texlive-latex-graphics for texlive-latex-fncychap);
>
> Correct. The old importer didn’t know about dependencies. The newer
> importer uses tlpdb to get a list of dependencies.
AFAIU, this is not sufficient. All dependencies do not appear in
"texlive.tlpbd". For example, `texlive-halloweenmath' has no "depend"
entry in the tlpbd. Yet, it requires both texlive-amsmath and
texlive-pict2e (i.e., "halloweenmath.sty" contains
"\RequirePackage{amsmath,pict2e}").
So, unless I'm mistaken, most dependencies have to be resolved manually.
> All packages must be checked for completeness. All new packages I’ve
> added have been checked. All old packages must be checked before
> renaming them. The way to check them is to build them and then check
> the outputs with something like this:
>
> --8<---------------cut here---------------start------------->8---
> ,use (guix import texlive)
> ,pp (files-differ? "/gnu/store/…-texlive-amsfonts-fixed-59745/share/"
> "amsfonts")
> --8<---------------cut here---------------end--------------->8---
>
> This compares outputs with tlpdb.
I use this valuable tool, but this is somewhat tedious. Could this
become a test in the linter?
> Note that simple-texlive-package is far from perfect. We have many
> tex packages that require excessive workarounds to ensure that files end
> up in the correct location and that superfluous files are removed.
> simple-texlive-package should eventually take care of all of this, but I
> haven’t been able to make time to work on it.
We may need to update more Texlive packages to get a better grasp of the
changes required in `simple-texlive-packages'. When doing such updates,
I mostly copy and paste definition from previously updated packages,
which is a good thing. However, some translations seem complicated.
> All this work should be done on a separate feature branch.
Agreed.
Regards,