qemu-img in EPEL overrides kvm-qemu-img in RHEL

[Stephen John Smoogen]

On Mon, Mar 1, 2010 at 2:55 PM, Richard W.M. Jones <rjones at 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


-- 
Stephen J Smoogen.

Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning