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
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
qemu-img in EPEL overrides kvm-qemu-img in RHEL
