Hi Maxim,
Maxim Cournoyer <maxim.courno...@gmail.com> writes:
Hi Ian,
Ian Eure <i...@retrospec.tv> writes:
[...]
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.
Conventionally in Guix that'd be called nss-next.
Oh boy, naming things! :)
I’m aware of the -next convention, but I’m not sure it makes sense
here. It’s used primarily for newer versions packages in the same
release channel -- ex. the default Python in Guix is python@3.10,
but there’s python-next@3.12. At some point, python will get
promoted to 3.12.x -- the "next" name is a reflection of this;
it’s intended to be the next python package in Guix. Upstream has
a single release channel, with a sliding support window over those
releases.
The nss/nspr situation is somewhat different, as there are two
upstream channels ("rapid release" and "extended support
release"). ESRs are a subset of rapid releases, and the majority
of rapid releases never enter the ESR channel. Naming a rapid
release nss-next when it will almost never become promoted to the
nss package feels wrong to me.
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.
This all sounds reasonable to me. Thank you for thinking about
it and
proposing to improve the situation.
Thank you very much for your thoughts.
I opened 71832 which implements the first part of my nss proposal
and updates Librewolf, so if you have strong feelings about -next
vs. -latest, that might be the best place to raise them.
Thanks,
— Ian
