guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Proposal: nss updates


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

The nss package updates frequently, around once a month. It's also very low in the package graph, so a ton of stuff depends on it. The most recent update was a graft for security fixes, so we didn't have to rebuild everything, but the new Librewolf version once again requires an nss update. I'm considering options to balance update frequency vs. huge rebuilds.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]