Re: Proposal: nss updates

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Ian,

Ian Eure <ian@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