Am Wed, Apr 15, 2026 at 07:54:01AM +0200 schrieb apteryx: > I feel the most important part of this GCD is left aside: what are the actual > criteria defining whether a package is healthy (e.g., in what situation would > be reject a new package on grounds that it's unmaintained or the likes -- how > do we define unmaintained? 2 years without seing a release? 2 years without > seeing a commit? The package not being easily built and lacking custom patches > from distros like Debian to do so? -- this kind of criteria. > > If the intent is to leave it to humans to decide on a case by case basis (the > status quo), then this GCD doesn't seem to bring much to the table.
The current deprecation policy gives criteria, so the status quo is not that people decide arbitrarily; from https://guix.gnu.org/manual/devel/en/html_node/Deprecation-Policy.html "Package removal": "Packages whose upstream developers have declared as having reached “end of life” or being unmaintained may be removed; likewise, packages that have been failing to build for two months or more may be removed." A few sentences later: "this applies even when the removal has additional motivations such as security problems affecting the package" If followed by the letter (which we did not do in the past), this would be extremely restrictive: Building packages could only be removed if they are expressly declared as unmaintained by upstream, even if they had security problems. The proposal expands the number of reasons a package may be removed: "## Removal of not building packages (...) such a package immediately becomes a removal candidate (...) ## Removal of building packages There are various reasons while packages may become removal candidates although they still build: For instance we may have a newer version of the same package in Guix, maintenance has stopped upstream, or the package is not adequately maintained in Guix. ### Removal candidates that are building packages with dependent packages (...) security vulnerabilities (...)" This is admittedly a bit vague, but it gives concrete cases where normally we would remove a package. I think we need to leave some room for human judgement. For instance, we have had the case that a package was unmaintained upstream and caused us maintenance problems, but we kept it since it was still widely used by some community. Conversely, we came close to removing ungoogled-chromium as "not adequately maintained in Guix" when we had nobody updating it for a long time (well, "security vulnerability" would have been a good argument there as well). I think we should not fix mechanical criteria. > What are the desired outcome of this GCD? Doesn't it currently mostly document > how to do things like deprecating, that would better live in the > documentation? Well, it changes some things compared to what we currently do and what is currently mandated by the manual, so it requires a decision, thus a GCD. If the GCD gets adopted, the result will be transcribed into the manual, which is our day to day source of truth. Andreas
