[Openstack-devel] [Pkg-libvirt-maintainers] Why did you upload netcf 0.2.2 to SID after the freeze?

[Thomas Goirand]

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)