Re: Question about changing versioning for TeX Live packages

[Nicolas Goaziou via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org>]

Hello,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Well, if I read correctly, there is:
>
>   guix/build-system/texlive.scm:
>
>         (define %texlive-tag "texlive-2023.0")
>         (define %texlive-revision 66594)
>
>   gnu/packages/texlive.scm:
>
>         (define %texlive-date "20230313")
>         (define %texlive-year (string-take %texlive-date 4))
>
>
> And the issue seems:
>
>         (define-public texlive
>            (package
>             (name "texlive")
>             (version %texlive-date)

This is the monolithic TeX Live, which is not modified, and is therefore
off topic.

>         (define-public texlive-scripts
>           (package
>             (name "texlive-scripts")
>             (version (number->string %texlive-revision))
>
>
> Therefore, indeed it will be complicated to replace the ’version’ of
> ’texlive-scripts’ by something as ’2023’.
>
> But why not a ’version’ as something as ’texlive’?  Or just 2023XY?
> Where XY is something to determine as the month or something else.

Upstream uses version numbers such as "2024.2". I don't want to invent
another system.

> Are we speaking a change only for the package field ’version’?  Or is
> the discussion also about replacing the way to fetch from upstream?

I'm only changing the `version' field. For the record, "core-updates"
currently contains all TeX Live packages with their version switched to
"2024.2". In the worst case, maybe a notice in the guix news will be
sufficient.

Regards,
-- 
Nicolas Goaziou