Hello, Simon Tournier <zimon.touto...@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
