> 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'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'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.
why not bring Debian's guix version to closely follow vanilla guix's releases? Is it because Debian wants to guarantee that a Debian release (such as trixie) only provides packages that stick to at most bugfix versions such that there are no breaking changes introduced?
5 comments
[ 2.6 ms ] story [ 19.4 ms ] threadIt's odd that guix is both rolling release but also uses older GCC versions; usually I'd expect those from very different cultures.
I say this as a long-term guix user.
4cf1acc7f30 + cherry-picked 71171538e12 + 1c78f71beb3 + a49536e3200 + 7f237f3e6ca