Re: 2Removal: handling circular dependencies / dropping tests before the binary?
> Note that having an unbuildable package in sid for several days, until > it's updated to a no-py2 version, is perfectly acceptable. please note that may not be fine with every maintainer. dont just drop packages without checking rdeps and/or if you know that will make packages uninstallable/unbuildable (unless you check with the people taking care of such packages first). btw sphinx-gallery d-b on pyhton-seaborh has been removed. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Re: 2Removal: handling circular dependencies / dropping tests before the binary?
On Sat, Sep 21, 2019 at 10:18:16AM +0100, Rebecca N. Palmer wrote: > Some Python 2 packages have circular (build-)dependencies, making it > impossible to remove them one at a time without breaking anything. Unless I'm missing something, this shouldn't be a problem, just go away and remove them all and upload them in roughly the same time? > --- Cut the cycle by removing one of the dependencies. > > This may mean skipping (some of) the tests, as Python build dependencies are > often actually test dependencies. There might be cases where it isn't > reasonably possible at all. Unless some of those don't have Python 3 packages in the archive yet, why removing py2 from one package would break building another, if that another has py2 parts removed too? Note that having an unbuildable package in sid for several days, until it's updated to a no-py2 version, is perfectly acceptable. -- WBR, wRAR signature.asc Description: PGP signature
2Removal: handling circular dependencies / dropping tests before the binary?
Some Python 2 packages have circular (build-)dependencies, making it impossible to remove them one at a time without breaking anything. One such cycle is seaborn, sphinx-gallery and matplotlib2 (#940873); I have not attempted to systematically check for them. How should these be dealt with? --- Cut the cycle by removing one of the dependencies. This may mean skipping (some of) the tests, as Python build dependencies are often actually test dependencies. There might be cases where it isn't reasonably possible at all. (Related question: if a package with a large test suite is being uploaded anyway, should we consider removing the Python 2 tests just to save buildd/debci resources?) --- Prepare all the required packages in salsa / experimental, then remove the entire cycle at once. This is easy if the cycle is small and otherwise ready to remove, but if one member has a big dependency tree, the whole cycle might have to stay for some time. (Related question: does it make sense to create no-Python2 salsa branches of one's regular modules (particularly any that need nontrivial changes) and mark them "please upload when the reverse dependencies have been cleared", even if they aren't part of a cycle?)
