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. > 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. -- Thanks, Maxim
