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
