unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Proposal: nss updates
@ 2024-06-27 14:13 Ian Eure
  2024-06-27 16:21 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
  2024-07-01  2:50 ` Maxim Cournoyer
  0 siblings, 2 replies; 10+ messages in thread
From: Ian Eure @ 2024-06-27 14:13 UTC (permalink / raw)
  To: guix-devel

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2024-08-18 14:11 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-06-27 14:13 Proposal: nss updates Ian Eure
2024-06-27 16:21 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-06-27 20:56   ` Ian Eure
2024-07-01  2:50 ` Maxim Cournoyer
2024-07-01 15:00   ` Ian Eure
2024-07-01 20:31     ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-07-02  0:06       ` Ian Eure
2024-07-02  1:57         ` Maxim Cournoyer
2024-08-15 23:38           ` Ian Eure
2024-08-18 14:10             ` Maxim Cournoyer

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).