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) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
