Re: Numpy migration?
Mattia Rizzolo <mattia@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
Reply to: