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