|
From: | Ian Eure |
Subject: | [bug#71832] [PATCH v6 2/3] gnu: Add nss-rapid. |
Date: | Sat, 17 Aug 2024 20:48:25 -0700 |
User-agent: | mu4e 1.8.13; emacs 28.2 |
Vagrant Cascadian <vagrant@debian.org> writes:
[[PGP Signed Part:Undecided]] On 2024-08-17, Ian Eure wrote:diff --git a/gnu/packages/nss.scm b/gnu/packages/nss.scm index 9224a8ed5a..1a684e6146 100644 --- a/gnu/packages/nss.scm +++ b/gnu/packages/nss.scm...+;; nss should track ESRs, but currently doesn't. 3.102.1 is the current ESR.+ (define-public nss (package (name "nss")Though I largely agree with the logic (e.g. nss *should* probably be packaging ESR versions in general)... it seems a little weird to include a comment about what the packaging for nss *should* do, even though it is not (yet) doing it... similar with embedding a specific "current" version, which will obviously become inaccurate before too long...Alternately, maybe moving the comment to where the nss version is actually defined; to give someone pause when considering updating theversion?Or maybe this belongs in a separate discussion on guix-devel and/or bug?
I started a discussion about nss earlier this year[1], and some of the changes in this patch set are a result of that. The long and short of it is that nss should track ESRs only, and it could do that now, but the process to update it is murky to me due to it causing a lot of rebuilds. I asked for some advice on that a couple days ago[2]. The comment is left in the hopes that a well-meaning contributor doesn’t update it to a non-ESR version before the ESR updates can be worked out, which would set the timeline for that change back by a year.
If you have guidance on how to update a package low in the graph, I’d appreciate hearing!
+;; nss-rapid tracks the rapid release channel. Unless your package requires a +;; newer version, you should prefer the `nss' package, which tracks the ESR+;; channel. +;; +;; See https://wiki.mozilla.org/NSS:Release_Versions +;; and https://wiki.mozilla.org/Rapid_Release_Model + +(define-public nss-rapidMixed feelings on rapid vs. latest ... latest is a bit more consistentwith other guix packages, though "rapid" is the terminology that upstream uses here.
Yes, agreed that the terminology situation isn’t ideal. I don’t have a strong preference, but neither is there concensus around "latest." In the absence of strong concensus, and to avoid bikeshedding, I opted for reusing upstream terminology, but clarifying that in the package description and synopsis. I frankly do not care which is adopted, and it can be updated any time, since this is high in the package graph. I do think that if the package is named "nss-rapid", the synopsis/description should indicate that this is upstreams Rapid Release channel. It currently does, but would need some trivial editing should the package name change.
Both those points are, in my opinion, quite minor; I would not want toblock on those points alone!
I agree, and I appreciate your pragmatic approach here. Thanks, — Ian[1]: https://lists.gnu.org/archive/html/guix-devel/2024-06/msg00318.html [2]: https://lists.gnu.org/archive/html/guix-devel/2024-08/msg00074.html
[Prev in Thread] | Current Thread | [Next in Thread] |