Re: Use of %texlive-revision and %texlive-tag in tex.scm

[Nathan Benedetto Proença]

Thank you Xinglu for letting me know of Thiago's efforts.

And thank you Thiago for your work!

Thiago Jung Bauermann <bauermann@kolabnow.com> writes:

> Hello,
>
> Em segunda-feira, 5 de julho de 2021, às 14:09:24 -03, Xinglu Chen 
> escreveu:
>> FYI, someone else is already workin on upgrading Texlive to 2021 on the
>> ‘core-updates’ branch (Texlive is already at 2020 on core-updates).
>> 
>>   <https://issues.guix.gnu.org/49408>
>> 
>> Maybe you would be interested in helping out?
>
> Indeed, that would be awesome. One way to help would be with more testing 
> of the TeX Live 2021 patches. I’m not actually a TeX user, so the only 
> testing I did was building the “texlive*” packages, the Guix manual and 
> running the `tests/texlive.scm` test. It would be great to have someone who 
> actually uses TeX involved in this process. :-)
>
> Also of course feel free to propose or submit changes if you see anything 
> in the patches which you think could be improved.

As I type, I am building texlive from your repo, so that I can get some
use of it and see if I have suggestions.

> From the original email:
>
> Em segunda-feira, 5 de julho de 2021, às 11:03:46 -03, Nathan Benedetto 
> Proença escreveu:
>> You see, they give me the impression that Guix is really concerned about
>> upgrading *all* of texlive at once.
>> These variables tell me I should go to the file texlive.scm and bump the
>> tag and revision, and then handle all the broken hashes.
>
> That’s what I did. :-)
>  
>> Hence, it seems to me that any attempt to upgrade the texlive package
>> would have to be done in a separate branch, which would only be merged
>> into master when all the packages are upgraded.
>
> Yes, because updating texlive causes thousands of packages to be rebuilt. 
> For example:
>
> $ guix refresh --list-dependent texlive-bin | tr ' ' '\n'  | wc -l
> 2020
>
>> Is this the case?
>
> My impression from working on this TeX Live update is that this is indeed 
> the case.
>
>> And if so, why?
>
> I don’t know why, but it makes sense to me.
> As I mentioned before, I’m not a TeX user and I’m not familiar with its 
> ecosystem, but my impression is that TeX Live is produced and also supposed 
> to be consumed as a consistent whole. Mixing and matching packages from 
> different revisions of the TeX Live Subversion repository would mean that 
> you’re running a “Frankenstein”  which no one else is running¹, and so you 
> have bigger chances of running into problems that don’t affect anyone else.
>
>> In any case, as this may be a choice between shipping stable and
>> up-to-date packages, and as I am new to contributing to Guix, I found
>> fitting to ask.
>
> That is the reasoning which makes the current arrangement make sense to me.
> Note that there is a third choice: update all of TeX Live at once, but do 
> so more frequently and take the packages straight from the trunk branch, 
> rather than a tag. This is what upstream recommends, actually:
>
> https://tug.org/pipermail/tex-live/2021-June/047187.html

Of course, software is always more complex than you expect at the
outset.
Both the --list-dependents count and the email thread you linked provide
great arguments for treating TeXLive as a monolith, and I am glad you
started this work.

Honestly, TeXLive is so huge I cannot confidently say that I am
competent enough to test it.
It also seems to be a domain which is hard to automatically test.
I will actually work with this patch for the upcoming weeks and, and
comment on the patch or send my own patch if I find something.

> ¹ This the story I’m referring to, of course: https://xkcd.com/1589/

Sure, this is my canonical version.
I have heard rumors about someone called "Mary Shelley" exploiting the
fact that Frankenstein is public domain to release her own joke version
of the comic.