Path: csiph.com!news.mixmin.net!news.albasani.net!tahina.priv.at!bofh.it!news.nic.it!robomod From: Simon McVittie Newsgroups: linux.debian.maint.python Subject: Re: Packages depending on python-testtools are now RC: is bzr still a thing? Date: Mon, 16 Sep 2019 00:40:01 +0200 Message-ID: References: X-Mailbox-Line: From debian-python-request@lists.debian.org Sun Sep 15 22:32:03 2019 Old-Return-Path: X-Amavis-Spam-Status: No, score=-9.3 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, LDO_WHITELIST=-5, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no X-Policyd-Weight: using cached result; rate: -3.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-Mailing-List: archive/latest/17351 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/20190915223122.GA19321@espresso.pseudorandom.co.uk Approved: robomod@news.nic.it Lines: 77 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Sun, 15 Sep 2019 23:31:22 +0100 X-Original-Message-ID: <20190915223122.GA19321@espresso.pseudorandom.co.uk> X-Original-References: <5c8da6a2-309d-d8d8-e773-172a50b6e56e@debian.org> <2926378.PZRHtU5IR0@l5580> <2307d9b7-6010-04d8-ec10-f35dd81e70ea@debian.org> Xref: csiph.com linux.debian.maint.python:11816 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 ------------------- 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