Hi Jeremy, On Fri, Sep 09, 2022 at 01:55:46PM -0400, Jeremy Bicha wrote: > The Debian Janitor service is opening merge proposals to drop > "obsolete" dependency relations. I'm wondering what the justification > is for this? Does it significantly speed up apt upgrades? > > It's useful for packages to match dependencies and their versions in > debian/control with what's provided in the upstream build system > (meson.build, configure.ac, CMakeLists.txt etc.). > > It's perhaps more developer work to think about whether the versions > are so old that the Janitor will recommend their removal. So if the > Janitor is potentially requiring more developer mental energy, then > it's worth questioning whether it should be making these merge > proposals by default. > > I'm not sure that it's actually "best practice" to be dropping those > package version relationships. > > > For reference, I guess you can add 'gnome-shell' to your ignore list > for this feature. See > https://salsa.debian.org/gnome-team/shell-extensions/gnome-shell-extension-hide-activities/-/merge_requests/4 > for a brief explanation.
Sorry for the slow response. Some background: deb-scrub-obsolete "scrubs" a bunch of different things that have become unnecessary with newer Debian versions. By default, it'll drop things that have become unnecessary since $DEB_COMPAT_RELEASE (which defaults to stable - but can be overridden to older versions to ease backporting). There are different categories of changes: * obsolete maintscript entries for upgrades from versions older than that in $compat_release * depends on packages that are essential since $compat_release * build-depends on packages that are build-essential since $compat_release * replacing dependencies on "transitional dummy packages" with the real thing (if satisfiable since $compat_release) * conflicts with packages that are gone since before $compat_release * version constraints in build-depends or depends that are met by the package in $compat_release I think your comments are specifically about the last category, which are admittedly also the most common. (This does remind me that I should probably update the deb-scrub-obsolete manpage with this information) On dropping versioned constraints: The motivation for removing the obsolete version constraints is that for a lot of packages, the version constraint is meaningless (because incorrect) when the minimum version is ancient - and that's arguably worse than no minimum version being specified If you bump minimum versions as you run into build problems and you depend on a minimum version that's not been seen in the wild for years, it's likely the true minimum version is actually more recent, but you wouldn't know if the version in unstable is newer. This means that when e.g. backporting, you can't really rely on the minimum version. While the above may be true for some packages (certainly for a quite a lot of mine), there is another set of packages where these version constraints are better curated to always match whatever upstream defines. The premise that they're meaningless doesn't hold there (assuming upstream keep their dependencies list up to date - but that's a different problem), and they can be helpful in e.g. backporting. My impression is that the packages in e.g. the GNOME team fall into this category. As you may have seen, there is now a --keep-minimum-depends-version flag for deb-scrub-obsolete that disables this last category of changes. Going forward: Two things I will do: * update the deb-scrub-obsolete manpage to document the * add an FAQ item to the janitor page about this Perhaps --keep-minimum-depends-version should be the default, with an option to drop unnecessary minimum depends versions? It would be ideal if there was some way of determining whether a package's minimum version depends were curated in some way (e.g. synced with upstream) so we don't a flag, but I can't think of a good way of doing that. Another approach would be to somehow verify that the minimum versions are correct (by building on a much older Debian and pulling in new packages as necessary? Seems challenging, but perhaps not impossible). Let me know what you think. Cheers, Jelmer