Re: 2Removal: handling circular dependencies

[Simon McVittie <smcv@debian.org>]

On Wed, 23 Oct 2019 at 23:05:39 +0100, Rebecca N. Palmer wrote:
> - One big tangle (159 packages).  This probably needs breaking up:
> --- Some of it involves documentation tools (e.g. sphinx).  These cycles can
> be broken by using the Python 3 version of the tool.

You've listed dbus-python as being part of this cycle, but since version
1.2.10-1 it only Build-Depends on sphinx-common, python3-sphinx and
python3-sphinx-rtd-theme. Is that enough to remove it from this cycle?

I removed the block when I made that change, but someone('s script?)
seems to have added it back? I can't remove python-dbus and close the
2removal bug yet, because lots of packages still depend on python-dbus.

I also can't see how -sphinx would depend directly or indirectly on
-dbus. Perhaps some of the blocks have been added the wrong way round?

I wonder whether parts of the 159-package cycle are actually smaller
cycles with non-trivial intersection, such as:

     python-sphinx --D--> sphinx-common
          | ^      <--S--
          D S
          v |
     python-alabaster

I'd tend to think of that as two intersecting 2-package cycles, rather
than one larger cycle.

> (Assuming we're still using "broken Suggests are not
> allowed": this has previously been discussed, I forget where.)

I think that's much too strong, particularly during a
transition. Transitions from unstable to testing only look at
(Pre-)Depends and Build-Depends(|-Arch|-Indep), although in general we
also consider broken Recommends to be a serious bug if anyone notices
them (due to Policy §2.2.1 "must not require or recommend a package
outside of main for compilation or execution").

Suggests are specifically not considered by Policy §2.2.1 (packages in
main are allowed to suggest packages that are in contrib, in non-free,
or not in the archive at all) and the pattern of cyclic Depends in one
direction, and Recommends or Suggests in the other, is extremely common.

    smcv