Mattia Rizzolo <mat...@debian.org> writes: > The way forward in cases like these is for the package that originally > cuased the breakage (i.e. numpy) to declare a versioned Breaks on the > borken and now fixed package (i.e. astropy (<< 3.1-1)). This way > britney and debci will know they have to test numpy and astropy > together, and will be able to correctly migrate to testing at the same > time, and properly avoid a situation when two incompatible packages > are installed. > Maybe you could open a bug on numpy to get the maintainer to add the > breaks.
I'll do tonight. It however looks a bit suboptimal: when the CI test with a new version fails for an old reverse dependency, then the new version obviously breaks that old package. So, the breakage could be detected (and taken into account) automatically. Why do we need a manual action then? >> Another CI problem is python-astropy, which is the Python 2 version of >> Astropy. python-astropy is going to be removed as soon as there are no >> backward dependencies left; however there is still some cruft in >> unstable that depends on python-astropy. But this should not hinder >> numpy to migrate. > > I don't understand this, I don't see any python2-related issue right > now. Could you please expand? The new python-numpy breaks python-astropy in testing. Python-astropy is however going to be removed completely; it has however some cruft rdeps left in unstable. So, it cannot removed from unstable now, and therefore still remains in testing and (unnecessarily) blocks the numpy migration. Python-astropy already has an RC bug, but its autoremoval from testing is still not even announced yet. The migration blocking CI tests seem to cause much more headaches than just "fix your bugs"... Best Ole
