Removing Guix from Debian
lwn.net
Removing Guix from Debian
1–10 of 49 posts
Re: Removing Guix from Debian
#2> For example, he has had to maintain various Guile dependencies, and deal with the fact that Guix uses ""fairly old"" GCC versions whereas Debian usually ships the latest GCC version available for a given release.
It's odd that guix is both rolling release but also uses older GCC versions; usually I'd expect those from very different cultures.
Re: Removing Guix from Debian
#3It's a shame that yet another project (bcachefs in Linux kernel) and now guix are getting ostracized out of mismanagement... on whoever's part, although in all honestly, and this is a hot take mind you; guix should either be run on bare metal, to take advantage of its bootstrap-from-source, thus avoiding debian in the first place, OR be running as guest, in some fantasical gnu hurd environment, thus forgoing linux.
I say this as a long-term guix user.
Re: Removing Guix from Debian
#4> For example, he has had to maintain various Guile dependencies, and deal with the fact that Guix uses ""fairly old"" GCC versions whereas Debian usually ships the latest GCC version available for a given release. It's odd that guix is both rolling release but also uses older GCC versions; usually I'd expect those from very different cultures.
It seems that it doesn't build with releases of GCC from April 2025 onward, at least with default settings, because it doesn't build with the C23/C++23 standards.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1096790
Maybe such changes are more substantial than the typical differences between GCC releases?
Re: Removing Guix from Debian
#5It's a shame that yet another project (bcachefs in Linux kernel) and now guix are getting ostracized out of mismanagement... on whoever's part, although in all honestly, and this is a hot take mind you; guix should either be run on bare metal, to take advantage of its bootstrap-from-source, thus avoiding debian in the first place, OR be running as guest, in some fantasical gnu hurd environment, thus forgoing linux. I…
> I say this as a long-term guix user.
Curious, what is your need / use case? I typically just stick to the package manager for whatever OS I install, if I don't like theirs, I find a new OS.
Re: Removing Guix from Debian
#6I've been meaning to share these results in a more appropriate place, but for what it's worth, the proof-of-concept script for the recent Guix CVEs bisects to a Jan 2023 commit, so it's not clear that released versions are affected.
4cf1acc7f30 + cherry-picked 71171538e12 + 1c78f71beb3 + a49536e3200 + 7f237f3e6ca
Re: Removing Guix from Debian
#7> For example, he has had to maintain various Guile dependencies, and deal with the fact that Guix uses ""fairly old"" GCC versions whereas Debian usually ships the latest GCC version available for a given release. It's odd that guix is both rolling release but also uses older GCC versions; usually I'd expect those from very different cultures.
It seems that it doesn't build with releases of GCC from April 2025 onward, at least with default settings, because it doesn't build with the C23/C++23 standards. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1096790 Maybe such changes are more substantial than the typical differences between GCC releases?
Surely if that's all they would just build with an explicit -std=whatever setting?
Re: Removing Guix from Debian
#8It's a shame that yet another project (bcachefs in Linux kernel) and now guix are getting ostracized out of mismanagement... on whoever's part, although in all honestly, and this is a hot take mind you; guix should either be run on bare metal, to take advantage of its bootstrap-from-source, thus avoiding debian in the first place, OR be running as guest, in some fantasical gnu hurd environment, thus forgoing linux. I…
> It's a shame that yet another project (bcachefs in Linux kernel) and now guix are getting ostracized out of mismanagement... on whoever's part,
I'm not even sure it's mismanagement, just incompatible approaches. Debian ships a coherent system, with a minimal (preferably one) versions of each library per version of the distro, and each version of the distro is maintained together for a fairly long time with as close as possible to only bug fixes as changes. And that's 100% valid in its own context. Guix apparently prefers rolling release. That's also 100% valid in its own context. But those two contexts don't mix well, through no fault of either party.
> although in all honestly, and this is a hot take mind you; guix should either be run on bare metal, to take advantage of its bootstrap-from-source, thus avoiding debian in the first place,
While I also see the appeal to going pure guix, the cross pollination is good for both projects, especially (IMHO) guix. This provided a gentler on-ramp to using guix at a smaller scale without the flying leap that is switching distros outright, and (per the article) the Debian maintainer(s?) have found reproducibility problems while doing their work which is quite valuable to guix.
> OR be running as guest, in some fantasical gnu hurd environment, thus forgoing linux.
Subhurds are really cool, but I would argue there are lots of practical uses that don't really need to go that far.
Re: Removing Guix from Debian
#9It's a shame that yet another project (bcachefs in Linux kernel) and now guix are getting ostracized out of mismanagement... on whoever's part, although in all honestly, and this is a hot take mind you; guix should either be run on bare metal, to take advantage of its bootstrap-from-source, thus avoiding debian in the first place, OR be running as guest, in some fantasical gnu hurd environment, thus forgoing linux. I…
> I say this as a long-term guix user. Curious, what is your need / use case? I typically just stick to the package manager for whatever OS I install, if I don't like theirs, I find a new OS.
Not the GP, but: For Guix in general? That's easy to answer:
(1) Making things reproducible. That is one of the main reasons. And not only installed system packages. You can also use it to build reproducible projects you develop, if the dependencies are available on Guix.
(2) The other one is installing software, that your distribution doesn't have in standard repos.
Re: Removing Guix from Debian
#10It's a shame that yet another project (bcachefs in Linux kernel) and now guix are getting ostracized out of mismanagement... on whoever's part, although in all honestly, and this is a hot take mind you; guix should either be run on bare metal, to take advantage of its bootstrap-from-source, thus avoiding debian in the first place, OR be running as guest, in some fantasical gnu hurd environment, thus forgoing linux. I…
Just using Guix requires a pretty substantial amount of administrative work. I'd imagine maintaining it is even more intense and that's why they're running into issues like this.
You have to be pretty slow to be outrun by Debian of all distros.