Hello, Am Tue, May 12, 2026 at 08:59:47AM +0200 schrieb yelninei--- via Development of GNU Guix and the GNU System distribution.: > As an example > https://codeberg.org/guix/guix/commit/641992f1ee4d47ed24070e8b6dc3e79d1fb180b0 > introduced 2 new versioned doxygen symbols and made doxygen an alias to the > older version to prevent rebuilds. > How should this get resolved when doxygen gets updated in the future? The > logical way is to also remove the obsolete doxygen packages breaking every > downstream depending on the versioned symbols.
an older version of a package is treated just like any other. There being a newer version around is a potential reason for removing (quotations from GCD 006): "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 (...)" Once these are leaf packages: "### Removal candidates that are building leaf packages 1. Leaf packages that by their nature are used mainly as inputs to other packages (for instance libraries, but also older compiler versions) require build farm capacity and maintenance work for little to no gain; they may be removed following the above process, assuming that there is no opposition to the removal or that consensus for the removal has been reached." So pull request, three weeks wait, gone (unless reasons are brought forward to keep the package, which is unlikely in this case). During the waiting period, people still using the variable can react by copy-pasting it into their channel, for instance, or by updating its dependents. > The problem with this is that now that e.g a newer doygen is available no one > has an incentive to try to update the default one anymore as the immediate > problem is fixed and the default doxygen lives forgotten in the corner. Yes, I agree that this tends to happen. We need more people doing tidying up work ;-) Actually it is already a lot of work to update packages that depend on old versions, and some of them will not be updatable; then the question whether to remove these becomes thorny. Andreas
