circular dependency when building LaTeX?

[Thiago Jung Bauermann]

Hi Phelype,

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 
that information.

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.

-- 
Thanks,
Thiago