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.
> >> 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.
Oh, sorry. I didn't realize python-astropy is a different source
package…
> 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.
Maybe you could ask the release team to hasten the removal of
python-astropy and rdeps from testing? If the plan is to not relase it
in buster I don't see a reason to keep it further.
> The migration blocking CI tests seem to cause much more headaches than
> just "fix your bugs"...
Well, from what I see, it has helped a lot in this half a year detect a
ton of regressions that would have otherwise bothered several people in
a later moment…
For sure it's not just "fix your bugs" but more like "fix your bugs AND
all your rdeps", in fact you'd expect the maintainer of the package
breaking everything to be a tad more proactive, but in many cases like
this, it's not.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Attachment:
signature.asc
Description: PGP signature