unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Thiago Jung Bauermann <bauermann@kolabnow.com>
To: "Nathan Benedetto Proença" <nathan@vieiraproenca.com>,
	guix-devel@gnu.org
Cc: Xinglu Chen <public@yoctocell.xyz>
Subject: Re: Use of %texlive-revision and %texlive-tag in tex.scm
Date: Mon, 05 Jul 2021 21:24:46 -0300	[thread overview]
Message-ID: <10041904.uO1rOqVNRx@popigai> (raw)
In-Reply-To: <87bl7git6j.fsf@yoctocell.xyz>

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.

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

-- 
Thanks,
Thiago

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




  reply	other threads:[~2021-07-06  0:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-05 14:03 Use of %texlive-revision and %texlive-tag in tex.scm Nathan Benedetto Proença
2021-07-05 17:09 ` Xinglu Chen
2021-07-06  0:24   ` Thiago Jung Bauermann [this message]
2021-07-06 18:00     ` Nathan Benedetto Proença
2021-07-06  9:48 ` Bengt Richter
2021-07-06 18:28   ` Nathan Benedetto Proença
2021-07-07  8:38     ` Bengt Richter

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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=10041904.uO1rOqVNRx@popigai \
    --to=bauermann@kolabnow.com \
    --cc=guix-devel@gnu.org \
    --cc=nathan@vieiraproenca.com \
    --cc=public@yoctocell.xyz \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).