Re: Proposal: nss updates

[Ian Eure <ian@retrospec.tv>]

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Hi Ian,
>
> Ian Eure <ian@retrospec.tv> writes:
>
> [...]
>
>> Concretely:
>>
>> The current nss package should stay how it is.  When the next 
>> ESR
>> happens, it should update to that (ungrafting nss at the same 
>> time),
>> and track ESR releases only from that point forward.  I don’t 
>> think it
>> would make sense to downgrade the current 3.99 package to the 
>> 3.91
>> ESR, so this will be a little funky until that release happens.
>>
>> The latest version of nss should be added as a second package, 
>> named
>> "nss-latest", bound to `nss-latest'.  It should track updates 
>> as
>> frequently as needed.
>
> Conventionally in Guix that'd be called nss-next.
>

Oh boy, naming things!  :)

I’m aware of the -next convention, but I’m not sure it makes sense 
here.  It’s used primarily for newer versions packages in the same 
release channel -- ex. the default Python in Guix is python@3.10, 
but there’s python-next@3.12.  At some point, python will get 
promoted to 3.12.x -- the "next" name is a reflection of this; 
it’s intended to be the next python package in Guix.  Upstream has 
a single release channel, with a sliding support window over those 
releases.

The nss/nspr situation is somewhat different, as there are two 
upstream channels ("rapid release" and "extended support 
release").  ESRs are a subset of rapid releases, and the majority 
of rapid releases never enter the ESR channel.  Naming a rapid 
release nss-next when it will almost never become promoted to the 
nss package feels wrong to me.


>> While I’d prefer having the packages named "nss-esr" and "nss", 
>> I
>> think the ESR should get the more prominent "nss" name, which 
>> should
>> make it easy for developers to do the right thing -- if a bunch 
>> of
>> packages depend on nss-latest, we’re back to the initial 
>> problem.
>> Code comments documenting this would also be added.
>>
>> We might also want to adopt this approach for nspr.
>>
>> I’m not sure about nss-certs; I think that should probably 
>> track the
>> nss ESR, and I don’t think there’s a compelling need for a 
>> package
>> tracking the rapid release channel.  I do want to improve this 
>> package
>> by having it reuse the origin of nss instead of duplicating it.
>>
>> Does all this seem reasonable to everyone?  If so, I can start 
>> sending
>> patches.
>
> This all sounds reasonable to me.  Thank you for thinking about 
> it and
> proposing to improve the situation.
>

Thank you very much for your thoughts.

I opened 71832 which implements the first part of my nss proposal 
and updates Librewolf, so if you have strong feelings about -next 
vs. -latest, that might be the best place to raise them.

Thanks,

  — Ian