Proposal: nss updates

[Ian Eure <ian@retrospec.tv>]

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