Hello.
Back again to the discussion about EPEL packages that override their RHEL counterparts...
RHEL5 contains kvm-qemu-img-83-105.el5_4.22 that provides qemu-img = 0.9.1.kvm.83
EPEL however provides qemu-img-0.10.5-1.el5.2 so after installing e.g. python-virtinst from RHEL which requires qemu-img, the user will end up with qemu-img from EPEL and not kvm-qemu-img.
On Thu, Feb 25, 2010 at 6:20 AM, David Juran djuran@redhat.com wrote:
Hello.
Back again to the discussion about EPEL packages that override their RHEL counterparts...
Thanks for reminding this. Oi this is going to cause some pain. I have been doing just source name conflicts/overrides and not provide overrides. Am hoping to get something together this wekend to catch these.
RHEL5 contains kvm-qemu-img-83-105.el5_4.22 that provides qemu-img = 0.9.1.kvm.83
EPEL however provides qemu-img-0.10.5-1.el5.2 so after installing e.g. python-virtinst from RHEL which requires qemu-img, the user will end up with qemu-img from EPEL and not kvm-qemu-img.
-- David Juran Sr. Consultant Red Hat +358-504-146348
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Thu, Feb 25, 2010 at 9:29 PM, Stephen John Smoogen smooge@gmail.com wrote:
On Thu, Feb 25, 2010 at 6:20 AM, David Juran djuran@redhat.com wrote:
Hello.
Back again to the discussion about EPEL packages that override their RHEL counterparts...
Thanks for reminding this. Oi this is going to cause some pain. I have been doing just source name conflicts/overrides and not provide overrides. Am hoping to get something together this wekend to catch these.
Ok one issue I found is that this package does not seem to be on the DVD's I was using to test for incompatibilities (it also turns out that this is x86_64 only which I hadn't looked at stupid me). Thankfully CentOS does have them on the DVD's so I have switched to using them for the tests. The script I am using needs a lot of tweaking still things like ImageMagick and GraphicsMagick both provide vicar.so but not in conflicting ways.
Once upon a time, Stephen John Smoogen smooge@gmail.com said:
The script I am using needs a lot of tweaking still things like ImageMagick and GraphicsMagick both provide vicar.so but not in conflicting ways.
Well, if something requires vicar.so those two package conflict in that you may pull in the wrong (or at least unexpected) one. That gets back to a flaw in the way requires and depends are auto-determined; private .so files get "promoted" to public for RPM dependencies.
On Fri, 2010-02-26 at 19:52 -0700, Stephen John Smoogen wrote:
Ok one issue I found is that this package does not seem to be on the DVD's I was using to test for incompatibilities (it also turns out that this is x86_64 only which I hadn't looked at stupid me).
The kvm-qemu-img actually is on the RHEL5.4 DVD but it's under the "VT" directory, not in "Server" with all the rest.
On Mon, Mar 1, 2010 at 12:16 AM, David Juran djuran@redhat.com wrote:
On Fri, 2010-02-26 at 19:52 -0700, Stephen John Smoogen wrote:
Ok one issue I found is that this package does not seem to be on the DVD's I was using to test for incompatibilities (it also turns out that this is x86_64 only which I hadn't looked at stupid me).
The kvm-qemu-img actually is on the RHEL5.4 DVD but it's under the "VT" directory, not in "Server" with all the rest.
Yes. I ahd downloaded the i386 dvd's which of course its not. I need to download the two x86_64 dvd's and explode them to do my search. At the moment CentOS is working out as well it has everything on it in one space :). I really wish for RHEL-5.[67?] we had a "You asked for it, here is everything DVD".
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.
On Mon, Mar 01, 2010 at 09:55:25PM +0000, Richard W.M. Jones wrote:
because some of them are broken and should be inflicted on paying customers]
Cough "should NOT be ..."
Rich.
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
epel-devel@lists.fedoraproject.org