unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ian Eure <ian@retrospec.tv>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Proposal: nss updates
Date: Mon, 01 Jul 2024 08:00:02 -0700	[thread overview]
Message-ID: <87zfr12ev3.fsf@meson> (raw)
In-Reply-To: <87msn1965s.fsf@gmail.com>

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> 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.
>

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


  reply	other threads:[~2024-07-01 17:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zfr12ev3.fsf@meson \
    --to=ian@retrospec.tv \
    --cc=guix-devel@gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).