Hi Denis, On Thu, Oct 01, 2026 at 05:51:27PM +0200, Denis 'GNUtoo' Carikli wrote: > But I also do understand that things aren't magic, and that Debian has > strong requirements for extremely good reasons and that the problem > here is in Guix not in Debian: Guix should backport security fixes and > at the time of the package removal in Debian, I could not get people to > commit to do that in Guix.
Not so fast here. There are several distinct requirements at play an I don't think you stitched them together in a good way. Packages meant for stable releases should have security patches backported. This does not imply that all packages in Debian unstable must have security patches backported. It can be ok, to flag a package as not having such backports (via an RC bug) and then it'll be excluded from stable releases but can still be part of unstable. If guix is not meant for stable, it also cannot be part of testing. The reason for me to have filed a removal suggestion was RC bugs being unanswered. This can happen legitimately (e.g. for excluing a package from stable for lack of patch backporting). Indeed, #1112143 is such a bug and I think it is fair to mark it in such a way that it does not cause removal of guix. Now what makes me think guix should be removed is that nobody cared to fix #1108318 for over a year! Even unstable users deserve security updates and if we cannot provide them, the package should not be part of unstable. No backporting needed here. Just go to the next development release. > And given what happened at that time in Guix, I'm realist and I don't > think it is feasible to have Guix backport security fixes in older > releases (like Guix 1.4.0 when Guix 1.5.0 is the latest release), and > that doesn't work with Debian because Debian isn't a rolling release > distribution. I don't think backporting is a requirement for keeping guix in Debian. Updating the package however is. > I've managed to confirm that it's possible to technically make Trisquel > pull the guix package from Debian unstable. So this sounds like a way forward to me. > So instead of simply deleting the package, would it be possible to > instead move it to some other repository like the fasttrack > repository[2] or somewhere that can be pulled by Trisquel and ideally > Ubuntu as well? That also is an option, but having it in any kind of repository without being updated is a disservice to any user base. Unless the package is maintained (and the present one evidently is not), there is no point in figuring out where to host it. > - Guix would create a team that manages the backporting of patches > and potentially other critical fixes (like if guix packages are 100% > broken due to substitute server URL changes or similar). I don't think this is necessary for keeping the package in Debian. You can still do this for other reasons. > Since Guix was removed from Debian, Guix also committed to make more > regular releases as per GCD 005[1], so here I hope that releases will > be more regular than before, and that there would be less to > backport and to review, even if Guix is late as per the schedule in [1]. It is not completely removed yet. It is removed from stable and testing and this bug report attempts to do the last removal (from unstable). > But for instance I've no idea how, as an external contributor, how to > make https://salsa.debian.org/debian/guix.git have the guix 1.5.0 > revision (there is probably a process for that as the source > probably needs to be authenticated somehow). Exactly this is what would be necessary. I agree this is a non-trivial amount of work, but it is this work that is needed for keeping the package in any place. Just dumping vulnerable versions somewhere looks nice but is a disservice to anyone who consumes them. Helmut
