unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Nathan Benedetto Proença" <nathan@vieiraproenca.com>
To: guix-devel@gnu.org
Subject: Use of %texlive-revision and %texlive-tag in tex.scm
Date: Mon, 05 Jul 2021 11:03:46 -0300	[thread overview]
Message-ID: <87o8bgoo1p.fsf@archlinux.i-did-not-set--mail-host-address--so-tickle-me> (raw)

Hello!

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

   https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build-system/texlive.scm?id=f7692617b624a01615cf412773c4dad9a2deeb68

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
on

   https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/tex.scm?id=f7692617b624a01615cf412773c4dad9a2deeb68

An example is the following code:

  (define hyph-utf8-scripts
    (origin
      (method svn-fetch)
      (uri (texlive-ref "generic" "hyph-utf8"))
      (file-name (string-append "hyph-utf8-scripts-"
                                (number->string %texlive-revision)
                                "-checkout"))
      (sha256
       (base32
        "0lk7shx768sxvgr85y8bnmmnj8x4bbkgpxrz3z8jp8avi33prw83"))))

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
    (origin
      (method svn-fetch)
      (uri (texlive-ref "generic" "hyph-utf8"
                        #:texlive-tag "texlive-2019.3"
                        #:texlive-revision 51265))
      (file-name "hyph-utf8-scripts-51625-checkout")
      (sha256
       (base32
        "0lk7shx768sxvgr85y8bnmmnj8x4bbkgpxrz3z8jp8avi33prw83"))))

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!
Nathan


             reply	other threads:[~2021-07-05 14:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-05 14:03 Nathan Benedetto Proença [this message]
2021-07-05 17:09 ` Use of %texlive-revision and %texlive-tag in tex.scm Xinglu Chen
2021-07-06  0:24   ` Thiago Jung Bauermann
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=87o8bgoo1p.fsf@archlinux.i-did-not-set--mail-host-address--so-tickle-me \
    --to=nathan@vieiraproenca.com \
    --cc=guix-devel@gnu.org \
    /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).