Hi Guixers,
A while back, I proposed splitting the nss package into two, one
for the ESR, and one for the rapid release. Because LibreWolf
tracks the Firefox Rapid Release channel, it needs a newer nss
than what Guix has fairly frequently, around 2-3 times a year.
However, the nss package is low in the graph, and upgrading it
triggers ~15k rebuilds. Splitting this into an
infrequently-updated package tracking ESR, which most things can
use, and a separate package tracking the rapid release channel,
which LibreWolf (and anything else needing a newer version) can
use is IMO a reasonable way to balance browser security updates
vs. frequent huge rebuilds. I added the nss-rapid package to
unblock LibreWolf, with the intent that when the next nss ESR
happened, the nss package would get updated (and ungrafted). That
release happened a while back, and #73152 has patches to fully
implement the split and update nss to the latest ESR.
The standard Guix process for updating packages low in the graph
are to push to a branch, let QA build substitutes, then merge[1].
Unfortunately, QA is extremely bogged down, which means this is
effectively impossible, because by the time it builds the branch
-- if it ever does -- so much has changed in master that the work
likely needs a rebase, starting the whole process over again.
What are the options for large updates like this? Thinking it
through, there seem to be three paths, in rough order of best to
worst:
1. Fix QA. I don’t know what’s wrong, or have a sense of what it
would take to fix. A one-week freeze on commits to let it catch
up? Moving to faster hardware so it can keep up with the pace of
development? Fixing QA seems like the best option, but also the
least clear and most difficult.
2. Push to a nss-updates branch and have Cuirass on
ci.guix.gnu.org do the builds, then merge. I’m not sure what’s
involved in doing this, likely someone would need to add a
specification to Cuirass for it to work.
3. Push to core-packages-team. Since this is already building in
CI and nss is arguably a core package, this makes sense to me.
The downside is that it’s not clear how long it’ll be until that
merges, and if we’re in another situation where LibreWolf has a
security update that requires a NSS update, will cause conflicts.
It also looks like the core-packages-team branch has been broken
since 23 Jan[2], which presents further difficulties.
4. Merge to master and break substitutes for a few days.
Any other options I haven’t considered?
Thanks,
-- Ian
[1]: See `(guix) Managing Patches and Branches'.
[2]: https://ci.guix.gnu.org/jobset/core-packages-team
