|
From: | Ian Eure |
Subject: | Proposal: nss updates |
Date: | Thu, 27 Jun 2024 07:13:11 -0700 |
User-agent: | mu4e 1.8.13; emacs 28.2 |
Mozilla has strong compatibility guarantees for nss, so the risk of packages breaking is very small. This is purely about the cost in CPU time to build and bandwidth to transfer packages.
Mozilla provides an ESR channel for nss, but Guix doesn't use it — we went from 3.88.1 to 3.99, skipping 3.91, which is the current ESR.
I think the default nss in Guix should be the ESR, but we should also have a package for the latest nss, for stuff which needs it. This would let us update to the most recent nss without rebuilding so much, and only eat that cost when there’s a new ESR -- this happens approximately once a year.
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.
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.
Thanks, — Ian
[Prev in Thread] | Current Thread | [Next in Thread] |