circular dependency when building LaTeX?
Thiago Jung Bauermann
bauermann at kolabnow.com
Tue Jul 6 21:54:53 CEST 2021
Em sábado, 26 de junho de 2021, às 19:11:49 -03, Phelype Oleinik escreveu:
> On 6/26/21 18:23, Thiago Jung Bauermann wrote:>
> > This isn’t just a theoretical concern. Guix has a mechanism called
> > “package transformations”¹ where the user can specify a patch to be
> > applied to the package they are installing. Guix strives to make it
> > easy for users to modify the software on their systems.
> That sounds... dangerous :-)
> I have no idea about Guix, so apologies if I'm nonsensing here, but this
> mechanism seems (from what I understood) to allow you to select a
> specific version of a package, but it rather uncommon that someone wants
> to update their xparse alone. Usually LaTeX users update packages when
> they have some new feature, and then this new feature requires a newer
> xparse, so usually a full upgrade is done, rather than a single package.
That’s true. This is a generic feature for all Guix packages, not specific
to LaTeX ones. And of course, if users customize a package then they get to
keep both pieces if it breaks. :-)
> But that's going off on a tangent...
> >> |xparse-generic.tex| and the |xparse-<date>.sty| you mention are no
> >> longer generated from |xparse.ins| because the development version
> >> moved
> >> to |ltcmd.dtx| in latex-base.
> >> Also, the |texlive-2020.1| tag is frozen and doesn't get any more
> >> updates. I'd recommend you use the |trunk| version (updated daily),
> >> which has the newest LaTeX, that I mentioned.
> > Interesting suggestion, thanks. Is trunk considered a stable version of
> > the TeX Live distribution that can be relied upon by users?
> Depends what you mean by stable. Most regulars in this mailing list use
> this version (which is what you get when you install vanilla TeX Live).
> Others prefer to distribute older "frozen" versions, to the example of
> Overleaf which is usually an year or so behind, but then you get users
> trying to upgrade their packages as I mentioned above, and issues begin.
Nice. I wasn’t expecting TeX Live to be a “rolling release” project. :-)
> >>> I also see a couple of xparse-<date>.sty. Their headers say that they
> >>> were “generated from xparse.dtx […] then adapted”. Does that mean
> >>> that
> >>> they were modified by hand after being generated by docstrip?
> >> Exactly (I am the one to blame :-). |xparse-generic.tex| was
> >> generated
> >> then modified by hand, but I forgot to add a similar note on its
> >> header.
> > Ok, that makes it unrealistic to try to generate it during the build
> > process. I’ll simply copy the versions that are in the CTAN package. As
> > you mention, this is a temporary situation that will go away after
> > texlive-2021.1, so the impact is limited.
> Good. Generating these versions themselves was quite troublesome
> because some are required to be loaded on top of the others, so baking a
> source to generate them is not really practical. I think these should
> not give your version-picking mechanism too much trouble, hopefully :-)
They didn’t. Learning the background and motivation for these files also
helped me understand what was going on. Thank you very much for providing
I modified l3packages to ship xparse-generic.tex (with a note about removing
it in the future) and also the two xparse-<date>.sty from /tex/latex/
l3packages/xparse/ in the Subversion repo.
More information about the tex-live