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
