On Saturday, January 05, 2019 08:30:28 PM Ole Streicher wrote: > Mattia Rizzolo <mat...@debian.org> writes: > > On Sat, Jan 05, 2019 at 04:02:35PM +0100, Ole Streicher wrote: > >> 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? > > > > Let me try to suggest you see from another side: the goal of the Breaks > > field is to prevent a given combination of known broken packages to be > > installed. > > Currently autopkgtest blocks the migration of numpy, but if there wasn't > > that block a Breaks should still be added, as the astropy in testing is > > not compatible with the new numpy. The fact that it hints britney to > > trigger the right tests is just a "side effects", the Breaks should be > > added nonetheless, theoretically; in practice, we rarely did it before > > autopkgtest started blocking the testing migration. > > I agree (with the explanation in your other mail) here; it just states > the fact that they really don't go together very well (at least in > situation similar to the specific CI test).
For what it's worth, I hit (AIUI) the same situation when I updated python- bleach. It broke python-readme-renderer. I reuploaded python-bleach with the breaks and a new version of python-readme-renderer (which worked with the new bleach) and both migrated two days later (since they both had autopkgtests). Scott K
