On Mon, Mar 1, 2010 at 2:55 PM, Richard W.M. Jones rjones@redhat.com wrote:
In reply to:
https://bugzilla.redhat.com/show_bug.cgi?id=569616
The background is that both qemu and KVM upstreams build a tool called /usr/bin/qemu-img. In theory the qemu-img tool built is the same and only one version of it would be needed. In reality differences in configuration of qemu or KVM (ie. block drivers) lead to different capabilities.
For example, if qemu is configured with the (mostly broken) VMDK block driver support, then qemu-img from the qemu package would also have VMDK capabilities. Whereas in RHEL KVM might decide not to compile in VMDK support because it is somewhat limited & broken, so KVM's qemu-img would not have this. You can find out what qemu-img supports by doing:
[qemu from Rawhide] $ qemu-img --help | grep Supported Supported formats: cow qcow vdi vmdk cloop dmg bochs vpc vvfat qcow2 parallels nbd host_cdrom host_floppy host_device raw
[qemu-img from EPEL 5] $ qemu-img --help | grep Supported Supported formats: nbd parallels qcow2 vvfat vpc bochs dmg cloop vmdk qcow cow host_device raw
[kvm-qemu-img from RHEL 5.4] $ qemu-img --help | grep Supported Supported format: parallels qcow2 vvfat vpc bochs dmg cloop vmdk qcow cow host_device raw
[qemu-img from qemu-kvm package, from a recent RHEL 6 beta -- I think the plan is to remove more of these drivers before RHEL 6 is released because some of them are broken and should be inflicted on paying customers] $ qemu-img --help | grep Supported Supported formats: cow qcow vdi vmdk cloop dmg bochs vpc vvfat qcow2 parallels nbd host_cdrom host_floppy host_device raw
Now it is my understanding that the plan is to build KVM's qemu-img as a binary called /usr/bin/kvm-qemu-img. I'm not sure if this will be just in RHEL 6, or will be in RHEL 5 too, although it seems like it might be too late for RHEL 5 because it would break binary compatibility. If KVM's qemu-img is built as kvm-qemu-img then there should be no conflict.
I don't think in any case it's a good idea to block the whole of qemu just for this. However blocking just /usr/bin/qemu-img from EPEL may be possible (on architectures where there is a conflict) if people are prepared for the fact that KVM's qemu-img might have slightly fewer features.
I hope the above is all correct -- it's not "official" advice from Red Hat.
Rich.
Thank you Richard. The things that could be done for this package are:
1) Block this package altogether in case of other conflicts. Not recommended. 2) Block the qemu-img package from being pushed. This would probably break other things too. 3) Change the qemu-img part of the spec-file to resolve the conflict so that the package does not get pulled in when the RHEL packages are brought in.
I would like to go for 3 if at all possible :). I just want to make sure things don't break for paying customers