On Wed, Mar 18, 2026 at 03:56:55PM +0100, Andreas Enge wrote: (...) > process: Anybody can propose to remove anything that still builds, but > the removal does not take place unless consensus is reached. (...)
I don't understand this point. I couldn't find any text about what happens if there is a dispute about a removal? If it's not there we should have clarity over handling disagreements since the "consensus" word merely means "we should all agree". It's also has an assumed, implicit meaning. We don't need a long definition, it could simply stated that a disagreement between committers/team members is escalated to the Maintainers, that would be explicit and clear. (...) > I have tried to reach out to Codeberg on IRC, but this is not an > "official" channel. I tried to do so on Matrix, which is supposedly > official, but turns out to be a maze of rooms that is difficult to > navigate. The last official way is to file an issue, which I find a bit > strange if one just wants to ask for help, and nothing is actually > broken. I tried to quickly check this morning what other Distros do, to see how much work we should be doing. >From what I can tell the regular release distributions (e.g. Debian, Ubuntu) >don't notify ahead of a release that a package is being removed. During the >upgrade, the package manager informs the user that packages will be removed, >and users can select to resolve it themselves. For the rolling release distributions it looks like Arch doesn't notify users ahead of time. Gentoo does notify users, and there's a nice write-up: - https://artemis.sh/2023/11/05/gentoo-mask-process.html - https://news.ycombinator.com/item?id=38151286 The summary is that the package manager notifies the user when they do an update that the package is "deprecated". The artemish.sh article says: - It prevents any new users from installing the package (this can be overridden, but its a conscious configuration change to do so). - It alerts anyone with the package already installed that they have a masked package installed, along with a comment as to why it’s masked. I couldn't find a policy document on it. It seems that OpenSUSE Tumbleweed does something similar, and actually allows the user the "lock" the package so they can keep it. I'm unclear what the situation is for NixOS / Nixpkgs, I couldn't find anything definitive. There was an RFC but it was abandoned, it has some interesting technical points: https://github.com/NixOS/rfcs/pull/33 For Guix, it sounds like it's reasonable for us to have a tag on Codeberg. We could consider improving our handling of deprecation for users. I'm actually not sure how explicit the notification is, and I don't think we give a reason [0]? The only other thing I can think of is that we could give users a way to specify that the Guix will not remove packages without confirmation, so an update would fail unless you explicitly specified that it was allowed to remove packages. Just an idea and not critical to this GCD. Steve / Futurile [0] https://guix.gnu.org/manual/1.5.0/en/html_node/Deprecation-Policy.html
