On 11/19/2012 06:37 PM, Guido Günther wrote:
It doesn't conflict with the version in experimental.
That's correct, sorry. I miss-read version numbers.
Although a breaks
would be prefereable over a conflicts. I'd prefer uploading 1.0.0 to
sid rather than reverting the netcf change.
Well, for me (and probably many others), it would have been better to
keep version 0.1.9-2 of netcf in Sid.
The current problem is isolated to installing libvirt0, because
libnetcf1 reverse dependencies are only libvirt0 (and python-libvirt).
However, apt-rdepends -r libvirt0 gives the following list:
- condor (>= 7.8.2~dfsg.1-1+deb7u1)
- eucalyptus-nc (>= 3.1.0-9)
- gnome-boxes (>= 3.4.3+dfsg-1)
- libguestfs-tools (>= 1:1.18.10-1)
- libguestfs0 (>= 1:1.18.10-1)
- libsys-virt-perl (>= 0.9.12-2)
- libvirt-glib-1.0-0 (>= 0.0.8-1)
- libvirt-ocaml (>= 0.6.1.2-1)
- python-libvirt (>= 0.9.12-5)
- ruby-libvirt (>= 0.4.0-1)
- virt-top (>= 1.0.7-1+b1)
- virt-viewer (>= 0.5.4-1)
- xenwatch (>= 0.5.4-3)
That's 13 packages, in which probably, an upload will have to be done in
Sid to fix who-knows-why. If you upload a new libvirt0 to Sid, then how
do you expect these to be updated in Wheezy thanks to an upload in Sid?
In any way, an upload of a newer libvirt version in Sid should be
coordinated with the release team, especially during the freeze. And at
this point, I'd bet that they would (rightly) refuse.
Thomas Goirand (zigo)