GNU bug report logs - #71832
[PATCH v5 0/3] [SECURITY] Add nss-rapid; update Librewolf to 128.0.3-1

Previous Next

Full log

Message #96 received at 71832 <at> debbugs.gnu.org (full text, mbox):

From: Ian Eure <ian <at> retrospec.tv>
To: Vagrant Cascadian <vagrant <at> debian.org>
Cc: 71832 <at> debbugs.gnu.org, guix-security <at> gnu.org
Subject: Re: [bug#71832] [PATCH v6 2/3] gnu: Add nss-rapid.
Date: Sat, 17 Aug 2024 20:48:25 -0700

Vagrant Cascadian <vagrant <at> 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 the
> version?
>
> 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-rapid
>
> Mixed feelings on rapid vs. latest ... latest is a bit more 
> consistent
> with 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 to
> block 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.