Re: Packages depending on python-testtools are now RC: is bzr still a thing?
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-maintainers@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
Reply to: