On the "next" packages, and packaging confusion.

On the "next" packages, and packaging confusion.

[Sharlatan Hellseher]

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


Hi Divya,

Speaking from Python/Golang/Astro teams perspective.

I see and use *-next where I need the latest package version but
updating inherited one would trigger a large amount of re-builds. It may
be swap on dedicated team branch when more packages start needing it.

In Golang, there are breaking changes versions which are specified in
module path and reflected in Guix' package names e.g.
go-github-com-<owner>-<project>-v2

If updating package does not trigger more than 300-400 related packages
there is not need to introduce *-next variant and it's reasonable just to
update to the latest version.

Hope it helps

Live well!

--
Oleg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: On the "next" packages, and packaging confusion.

[Divya Ranjan]

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

Hello Sharlatan,

That is understandable, but I guess you can already see how diverse these customs are between one ecosystem and another.

I was simply asking if these practices can either be documented clearly or made uniformly.

Regards,

Divya Ranjan


On 23 November 2024 15:34:24 GMT, Sharlatan Hellseher <sharlatanus@gmail.com> wrote:
>
>Hi Divya,
>
>Speaking from Python/Golang/Astro teams perspective.
>
>I see and use *-next where I need the latest package version but
>updating inherited one would trigger a large amount of re-builds. It may
>be swap on dedicated team branch when more packages start needing it.
>
>In Golang, there are breaking changes versions which are specified in
>module path and reflected in Guix' package names e.g.
>go-github-com-<owner>-<project>-v2
>
>If updating package does not trigger more than 300-400 related packages
>there is not need to introduce *-next variant and it's reasonable just to
>update to the latest version.
>
>Hope it helps
>
>Live well!
>
>--
>Oleg

Divya Ranjan, Mathematics, Philosophy and Libre Software

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

Re: On the "next" packages, and packaging confusion.

[Christopher Howard]

Hi, I'm not a Guix maintainer, but just thought I would mention that, regarding Emacs:

- There is an official, distinct branch for the next release (in this case, Emacs 30)
- They do have official "pre-test" releases, in the year before the release, which in this case were 30.0.91 and 30.0.92.
- Before that, i.e., before the pre-test releases, it appeared that guix was camping on 30.0.50 (or was it 51)?. I was fine with that, because the important thing (to me) is that the guix package emacs-next could provides a package definition that I could use (with shell -D) to build any commit in the 30 branch. I'm not sure, off-hand, how 30.0.50 was picked exactly.

So, for me at least, the important thing is that emacs-next is taken from the branch for the next release. And if it gets adjusted at the time the pre-tests are release, that is also nice.

-- 
Christopher Howard

On the "next" packages, and packaging confusion.

[Divya Ranjan via Development of GNU Guix and the GNU System distribution.]

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.