Hi, On Fri, Jun 20, 2025 at 08:58:11PM -0400, Philip McGrath wrote: > On Wed, Jun 11, 2025, at 4:58 PM, Ludovic Courtès wrote: > >> I'm wondering if we should separate "Guix installed as a packge > >> manager" into it's own package set. In the long run this would be a > >> building lock that allow us to align with Philip's suggestion of > >> following a more Nix-packages / Nix OS separation of releases. What do > >> you think? > > > > The NixOS/Nixpkgs distinction doesn’t really exist anymore (it used to > > be two separate repos but the two are necessarily tightly coupled), so > > I’m not sure what the suggestion is. > > > > The distinction I was thinking about was between the `nix` daemon and > command-line tool, developed at https://github.com/NixOS/nix and last > released on May 22 as version 2.29.0, and the Nixpkgs/NixOS package > definitions, developed at https://github.com/NixOS/nixpkgs and last released > on May 23 as version 25.05. IIUC, `nix` itself has a release cadence > independent of Nixpkgs/NixOS: e.g. the previous `nix` 2.28.0 release was on > April 4, whereas the Nixpkgs/NixOS 24.11 release was back in November. > > I think the https://github.com/NixOS/nix repository corresponds to the parts > of Nix or Guix needed to install on a foreign distribution, as reflected in > particular by the origin of Guix's nix@2.16.1 package. (...)
AIUI some/many distributions will only package 'releases', so it would mean doing a release of the parts of Guix that are used in the binary installer. I don't know enough to know if this is achievable for Guix - Philip if you would like to work on a follow-up GCD proposing it I would be happy to partner with you on it. For now, I've added the following in the section about possible future improvements: -- >8 -- >8 -- There are various improvements that could be made to the release strategy over time, such as: 1. Create separate releases of the Guix source necessary for installing Guix on a foreign distribution. This would mean that downstream Linux distributions that package Guix could have new release more often. 1. Adding an additional slower release cadence. This could be either a security and critical fixes branch strategy, such as implemented by Nix. Or it could be a slightly slower moving branch, such as implemented by SUSE SlowRoll. -- >8 -- >8 -- > On Mon, Jun 9, 2025, at 9:34 AM, Ludovic Courtès wrote: > >> ## Release artifacts > >> > >> Using the primary architecture tier and the package sets would involve > >> creating > >> the following release artifacts: > >> > >> - GNU Guix System ISO image > >> - GNU Guix System QCOW2 image > >> - ["the Guix System installation user interface on the ISO"] > > > > This omits two important things: > > > > • The binary tarball, used to install on top of another distro, for > > all “supported architectures” (Primary and Alternative). > > > > • The source tarball, as produced by ‘make dist’ (target audience is > > primarily downstream packagers, such as Debian). > > > > Reducing toil will be a matter of defining “supported architectures” in > > a reasonable way. > > For the source and binary tarballs used to install on foreign distros and for > downstream packaging, the case for regular releases seems clear. We expect > that people may choose to upgrade the Guix daemon relatively rarely, > especially if they (like me!) are getting it from downstream distro > packaging. Ideally, the scope of this would be small enough that backporting > important bug fixes and security updates would be feasible. (IIRC, the fix > for CVE-2024-52867 was not backported onto Guix 1.4.0: the recommendation in > the blog post was to use `guix pull` or wait for your distro packager to do > the cherry-pick the patches.) These are what I think correspond to the > https://github.com/NixOS/nix repository. > > For the Guix System UI+ISO+QCOW2, I am less clear on the benefits of > designated releases over rolling-release snapshots like those from > <https://guix.gnu.org/en/download/latest/>. (It is very possible that this is > because I don't know much about how the installer works. I only tried it once > or so, as an experiment: other times I have installed Guix System by first > installing Guix on a foreign distro and then using `guix system reconfigure`.) > > Nixpkgs/NixOS has both a rolling-release channel, nixos-unstable, and "stable > channels" like nixos-25.5, which "get conservative bug fixes and package > upgrades" and "are generally maintained until the next stable branch is > created". Guix does not currently have "stable channels", and I haven't heard > anyone proposing to change that at this juncture, so the only way to get bug > fixes and security updates is to use `guix pull` regularly. > > AIUI, this makes a release like Guix System 1.4.0 notably different than a > release like NixOS 25.5. If you use a NixOS 25.5 installer, you not only do > get version 25.5 of the installer itself, but also also default configuration > to use the nixos-25.5 channel, so you will continue to use the same major > versions of packages that you initially install, with only "conservative bug > fixes and package upgrades". With a Guix System 1.4.0 installer, on the other > hand, as soon as you do `guix pull && sudo guix system reconfigure > /run/current-system/configuration.scm && sudo herd restart guix-daemon`—which > you ought to do regularly—your package versions update the same as if you had > used a snapshot installer. > (...) I personally would love Guix to have a "stable" channel (as noted in the improvements section). But, after discussion with the GCD's sponsors I removed it because it was felt that this was too big a step - consequently the GCD was descoped to focus on "annual releases" and then other improvements can come later. Steve / Futurile
