[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Nathan Benedetto Proença
Subject: Use of %texlive-revision and %texlive-tag in tex.scm
Date: Mon, 05 Jul 2021 11:03:46 -0300


I am trying to upgrade the package texlive, first for me, but hopefully
for a patch, and I have a question regarding Guix policies.

As you can see on

the file guix/build-system/texlive.scm exposes two variables:

    (define %texlive-tag "texlive-2019.3")
    (define %texlive-revision 51265)

These variables are used throughout gnu/packages/tex.scm, as you can see

An example is the following code:

  (define hyph-utf8-scripts
      (method svn-fetch)
      (uri (texlive-ref "generic" "hyph-utf8"))
      (file-name (string-append "hyph-utf8-scripts-"
                                (number->string %texlive-revision)

Grep tells me there are 290+ occurrences of `%texlive-revision`.
What is the purpose of these variables?

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.

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.

Is this the case?
And if so, why?

I have the impression that if such "monolithic" upgrade is not a goal,
and "partial" our "per-package" upgrades are desirable, there may be
better solutions.

For example, we could add keyword arguments to texlive-ref and
texlive-origin, so the code above becomes something like this

  (define hyph-utf8-scripts
      (method svn-fetch)
      (uri (texlive-ref "generic" "hyph-utf8"
                        #:texlive-tag "texlive-2019.3"
                        #:texlive-revision 51265))
      (file-name "hyph-utf8-scripts-51625-checkout")

This would work right now, and we could eventually remove every use of
%texlive-revision and %texlive-tag, so they become implementation
details of the build-system texlive.scm; a fallback version.
And further down the road we may even decide to remove this fallback,
and make developers be explicit about their tags and revisions; this
could amount to a refactor which makes the keyword arguments into
required arguments, for example.

I also like the second version of the code because the hash already
pinpoints the tag and revision: both texlive-ref and texlive-origin use
these variables to find the correct files to download.
This just makes this dependency explicit.

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.

Thanks in advance!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]