On Sun, 15 Sep 2019 at 23:39:46 +0200, Thomas Goirand wrote: > reverse-depends takes sometimes forever in Sid for a reason I > can't figure out. And if I'm not mistaking, that's the only tool we have > that can check reverse dependencies in a meaningful way. Or is there a > better way? I've read others using a dak command, how?
Log in to the developer-accessible archive copy (mirror.ftp-master.debian.org, currently hosted on coccia.debian.org), and use "dak rm -R -n" (aka "dak rm --rdep-check --no-action"). Use "dak rm --help" for help. For the Python-2-removal transition, probably the most common query will be to ask what would be broken if you removed all the Python 2 binary packages from a source package, but kept the rest of the source package. For example, looking at https://tracker.debian.org/pkg/pygobject I can see that it builds binary packages python-gi, python-gi-cairo, python-gi-dbg, python-gi-dev, and python-gobject for Python 2 (plus some Python 3 binary packages which are not interesting for this transition), so I tried this: $ dak rm -R -n -b python-gi python-gi-cairo python-gi-dbg python-gi-dev python-gobject and got this result: Will remove the following packages from unstable: python-gi | 3.34.0-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x python-gi-cairo | 3.34.0-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x python-gi-dbg | 3.34.0-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x python-gi-dev | 3.34.0-1 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x python-gobject | 3.34.0-1 | all Maintainer: Debian GNOME Maintainers <pkg-gnome-maintain...@lists.alioth.debian.org> ------------------- Reason ------------------- ---------------------------------------------- Checking reverse dependencies... # Broken Depends: autokey: autokey-gtk avahi: avahi-discover ... # Broken Build-Depends: accerciser: python-gi-dev (>= 3.4.2) alacarte: python-gi-dev avahi: python-gi-dev ... Dependency problem found. How to interpret this: if we removed python-gi, python-gi-cairo, python-gi-dbg, python-gi-dev and python-gobject, then it would break Depends in binary packages autokey-gtk (from src:autokey), avahi-discover (from src:avahi) and so on; and would also break Build-Depends in accerciser, alacarte and so on. (I stopped quoting after "A" here.) If there is no dependency that would prevent the packages' removal, instead you would see: Checking reverse dependencies... No dependency problem found. To evaluate what would happen if entire source packages were removed, leave off the -b (aka --binary), and the package names will be interpreted as source instead of binary packages. For example, https://tracker.debian.org/pkg/pygobject-2 is Python-2-only (it's a legacy version of https://tracker.debian.org/pkg/pygobject) so you might run this: $ dak rm -R -n pygobject-2 When doing QA work and recommending that an unmaintained/broken source package is to be removed, the form without -b is usually the right one to use. smcv
