* On the "next" packages, and packaging confusion.
@ 2024-11-11 5:17 Divya Ranjan via Development of GNU Guix and the GNU System distribution.
0 siblings, 0 replies; 4+ messages in thread
From: Divya Ranjan via Development of GNU Guix and the GNU System distribution. @ 2024-11-11 5:17 UTC (permalink / raw)
To: guix-devel
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: On the "next" packages, and packaging confusion.
@ 2024-11-22 23:57 Christopher Howard
0 siblings, 0 replies; 4+ messages in thread
From: Christopher Howard @ 2024-11-22 23:57 UTC (permalink / raw)
To: Divya Ranjan via Development of GNU Guix and the GNU System distribution.
Cc: Divya Ranjan
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* On the "next" packages, and packaging confusion.
@ 2024-11-23 15:34 Sharlatan Hellseher
2024-11-23 15:53 ` Divya Ranjan
0 siblings, 1 reply; 4+ messages in thread
From: Sharlatan Hellseher @ 2024-11-23 15:34 UTC (permalink / raw)
To: divya; +Cc: guix-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: On the "next" packages, and packaging confusion.
2024-11-23 15:34 Sharlatan Hellseher
@ 2024-11-23 15:53 ` Divya Ranjan
0 siblings, 0 replies; 4+ messages in thread
From: Divya Ranjan @ 2024-11-23 15:53 UTC (permalink / raw)
To: Sharlatan Hellseher; +Cc: guix-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-11-23 15:56 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-11-11 5:17 On the "next" packages, and packaging confusion Divya Ranjan via Development of GNU Guix and the GNU System distribution.
-- strict thread matches above, loose matches on Subject: below --
2024-11-22 23:57 Christopher Howard
2024-11-23 15:34 Sharlatan Hellseher
2024-11-23 15:53 ` Divya Ranjan
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).