Am Sat, Mar 14, 2026 at 11:28:12PM +0100 schrieb Tomas Volf: > > ## Removal of outdated libraries which are leaves > Compared to the broken packages, this section raises an interesting > question, how will these libraries be located? Simply when someone > notices? Or e.g., any leaf package that has package of the same name, > but larger version?
Yes, this is like now - nothing is automated, and none of the things MUST happen. As long as nobody notices something can be dropped or works towards removing it, we will keep it in. > > Removing an outdated, but still building library that is a leaf in the > > dependency tree has almost as little impact as removing a broken > > package. > I am not sure I agree here. Users can have local packages that depend > on those libraries, so after the library removal their home environments > could no longer build (for example). As long as the variable is public, > I do not see any difference between a library and an application. This is the "almost" part. What people can do in any case (but this is also not a difference between libraries and applications) when something still building is removed, is to add it back to their own channel. I think they can even do so while the removal candidate is still in the main channel, as duplicate packages should just shadow each other (but it they are identical, this is fine). > > On the other hand, keeping the library also has little impact beyond > > wasting build farm capacity. > > We follow the same removal process as above, but the initial removal > > notification is prolonged from one week to three weeks. > I do not object too strongly here, although I prefer to keep working > code around, as long as it is working. I just want to make sure the > premise for your position here is correct, and I am not sure it is (see > the above). I think the emphasis is on "outdated", which is being discussed here as well: https://codeberg.org/guix/guix-consensus-documents/pulls/12 and will probably change a little. We should remove EOL "libraries" such as Python 2 or Qt 5 at some point in time, even if users' code may still rely on them; then it is on them to add the package back to their channel. > Is there a way for me, as a channel maintainer, to have a single commit > that works with Guix both before and after the package move? For > example, I get a notification that package `foo' will be moved from > `(gnu packages bar)' to `(gnu packages baz)'. What now? What changes > do I make to ensure no issues for users of my channel? I think that if to every file with a #:use-module (gnu packages bar) you add a #:use-module (gnu packages baz) you should be good to go before and after the move (and may possibly drop the first line after the move). > > The procedure for notifying channel maintainers (and interested users) > > is not fully thought out yet. > A simple bot that looks for issues with deprecation tag, and sends an > email to guix-deprecation mailing list? Interested parties can then > subscribe to that list. That sounds good. I would not know how to write such a bot. Or integrate some kind of hook with forgejo when an issue with a given tag is opened. I will try to enquire with Codeberg what we can do. Andreas
