On "next" packages and related confusions.

On "next" packages and related confusions.

[Divya Ranjan]

Hello,

As someone who’s been recently involved in packaging some software for GNU Guix I’m confused with certain choices, mostly with the [package]-next category. What should these next packages be? "More recent" than the non-next package? If so, how much more recent? One release ahead? Or is it supposed to follow the latest master release from the source repository of the package, and the non-next package would be the stable one?

None of the above options seem to satisfy, emacs-next does not follow the latest master, but it further away than one release from the stable. So what exactly does emacs-next follow for being updated? This is not only confusing, but I believe creating issues in packaging as well, someone has even consdiered packaging a "emacs-nextnext" [0].

A better solution is necessary, at least if not that we should decide what and how should the "next" packages be provided and packaged, emacs-next doesn’t even have a description. The next packages should have a _distinct_ description from the non-next ones, so that when the user is installing it they know that they’re installing not a stable, or more recent or whatever we decide as the distinguishing element between the two categories.

I’ve seen similar issues in trying to upgrade the ghc package as well, the ghc-next isn’t clear as to what its following [1].

A clearance of these confusions would be better for both package maintainers and end-users who don’t see much beyond the description, version and do `guix install'.

[1]: https://issues.guix.gnu.org/issue/47335
[0]: https://issues.guix.gnu.org/73281

Regards,
-- 
Divya Ranjan,
Philosophy, Mathematics, Libre Software.

Re: On "next" packages and related confusions.

[Ryan Prior via Development of GNU Guix and the GNU System distribution.]

-------- Original Message --------
On 11/11/24 9:10 AM, Divya Ranjan <divya@subvertising.org> wrote:

>  Hello,
>  
>  As someone who’s been recently involved in packaging some software for GNU Guix I’m confused with certain choices, mostly with the [package]-next category. What should these next packages be?


As your intuition hints, "next" is arbitrary. It indicates somebody's judgement that it would be inappropriate to update the main package to that version, perhaps because of instability or perhaps because the update would require a lot of rebuilds.

I think it would be appropriate if each "next" package had a code comment, or perhaps an addendum to its package description, describing how it relates to the main packaged version.

In case you don't know about "--with-latest", that's the supported way to install the latest master branch of a package. "-next" packages are not meant to closely track master.

Re: On "next" packages and related confusions.

[Divya Ranjan]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

Hello Ryan,

> I think it would be appropriate if each "next" package had a code comment, or perhaps an addendum to its package description, describing how it relates to the main packaged version.

I think the whole "next" category is problematic. Why not just have a version number of that package that's different from the "main" one? So instead of emacs-next have emacs-30.0.9 or whatever. At least here the choice of arbitrariness is visible. A "next" makes no sense.

> In case you don't know about "--with-latest", that's the supported way to install the latest master branch of a package. "-next" packages are not meant to closely track master.

Thank you for this, how can this be added when declaring a package in system or home configuration?

Regards,

Divya Ranjan, Mathematics, Philosophy and Libre Software

[-- Attachment #2: Type: text/html, Size: 943 bytes --]

Re: On "next" packages and related confusions.

[Philip McGrath]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

On Mon, Nov 11, 2024, at 7:50 PM, Divya Ranjan wrote:
> > I think it would be appropriate if each "next" package had a code comment, or perhaps an addendum to its package description, describing how it relates to the main packaged version.
> 
> I think the whole "next" category is problematic. Why not just have a version number of that package that's different from the "main" one? So instead of emacs-next have emacs-30.0.9 or whatever. At least here the choice of arbitrariness is visible. A "next" makes no sense.

One problem with this is that tools resolve a bare package name like "emacs" to the package with that name with the greatest version. So if, for example, the base package is following a LTS channel, or if there's a reason to package a pre-release version, adding "-next" to the name ensures that users don't accidentally end up with a newer-than-recommended version.

[-- Attachment #2: Type: text/html, Size: 1180 bytes --]

Re: On "next" packages and related confusions.

[Divya Ranjan]

"Philip McGrath" <philip@philipmcgrath.com> writes:

> On Mon, Nov 11, 2024, at 7:50 PM, Divya Ranjan wrote:
>
>  > I think it would be appropriate if each "next" package had a code comment, or perhaps an
>  addendum to its package description, describing how it relates to the main packaged version.
>
>  I think the whole "next" category is problematic. Why not just have a version number of that
>  package that's different from the "main" one? So instead of emacs-next have emacs-30.0.9 or
>  whatever. At least here the choice of arbitrariness is visible. A "next" makes no sense.
>
> One problem with this is that tools resolve a bare package name like "emacs" to the package with
> that name with the greatest version. So if, for example, the base package is following a LTS channel,
> or if there's a reason to package a pre-release version, adding "-next" to the name ensures that users
> don't accidentally end up with a newer-than-recommended version.

But that should be handled differently I believe. Since this only creates confusion. Can there be a way to sort of "pin" the release version to the namespace "emacs" and other versions to be emacs-x.x. Or at least remove the arbitrariness of emacs-next and keep it updated to the master like emacs-git in Arch.

Regards,
-- 
Divya Ranjan,
Philosophy, Mathematics, Libre Software.

Re: On "next" packages and related confusions.

[Simon Tournier]

Hi,

On Mon, 11 Nov 2024 at 15:10, Divya Ranjan <divya@subvertising.org> wrote:

> As someone who=E2=80=99s been recently involved in packaging some
> software for GNU Guix I’m confused with certain choices, mostly with
> the [package]-next category. What should these next packages be? "More
> recent" than the non-next package? If so, how much more recent? One
> release ahead?

There is no rule, to my knowledge.

I think the idea is:

 1. Update the package when possible.

 2. When the update is non-desirable because it leads to a world-rebuild
    or ecosystem world-rebuild, we provide some -next version.

In other words, if it=E2=80=99s not clear for you when the package needs to=
 be
under the -next category then it means it does not need :-) thus it=E2=80=
=99s a
regular update.

More recent means somehow new significant release. A good rule of thumb
that I use for what mean =E2=80=9Csignificant=E2=80=9C: a) this new release=
 fixes a
well-known security bug and b) I highly need and I cannot live without
one of the feature that the new release provides.

> None of the above options seem to satisfy, emacs-next does not follow
> the latest master, but it further away than one release from the
> stable. So what exactly does emacs-next follow for being updated?

About emacs-next specifically, well, the question is addressed to Emacs
team, right?  Hum, in case they are CC.


Cheers,
simon

Re: On "next" packages and related confusions.

[Liliana Marie Prikler]

Am Dienstag, dem 12.11.2024 um 19:00 +0100 schrieb Simon Tournier:
> > None of the above options seem to satisfy, emacs-next does not
> > follow the latest master, but it further away than one release from
> > the stable. So what exactly does emacs-next follow for being
> > updated?
> 
> About emacs-next specifically, well, the question is addressed to
> Emacs team, right?  Hum, in case they are CC.
When emacs is version N, emacs-next tails N+1.  Which means it *should*
currently be at 30.0.92, but no one has updated it to that yet.

Cheers