It's odd that guix is both rolling release but also uses older GCC versions; usually I'd expect those from very different cultures.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1096790
Maybe such changes are more substantial than the typical differences between GCC releases?
If more Guix users want to be seen and counted, to show how much of a need there might be to keep it despite the current issues, then there is a simple thing they can do… Or a less simple thing: the “without a community nor help” part seems rather significant to me in “But the Debian package maintainer has the almost impossible task to backport all the security fixes without a community nor help behind [maintaining it] and as things are going, this will probably lead to the Debian guix package being removed”.
4cf1acc7f30 + cherry-picked 71171538e12 + 1c78f71beb3 + a49536e3200 + 7f237f3e6ca
I say this as a long-term guix user.
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.
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.
(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.
It helps a lot on Chromebooks, where it's not straightforward to get a recent release.
It also helps to get up-to-date packages if you're a regular user and your admin doesn't have them for some reason (maybe RHEL or Ubuntu LTS.)
Or even just if your admin doesn't have the packages installed.
You have to be pretty slow to be outrun by Debian of all distros.
Like, as a user downloading packages, or a person packaging an application?
As a user downloading a package, it's been super easy for me and it's been years of running Guix with little to no issue (yet the benefits of rolling release, rollbacks, installing multiple versions of a given software etc.).
As for using it to package an application, I found the challenges mainly in the documentation. This was years ago and a lot of work has gone into improving the docs.
I'm curious what your experience has been.
