(In reply to Lubos Kocman from comment #0)
> Description of problem:
> 
> Hello,
> 
> seems like libguestfs has new rpm "virt-v2" which didn't make it to rhel 7.1

                                     ^ virt-v2v

> compose. RHEL-6 has the rpm listed in @virtualization-tools.
> 
> Could you please add it into comps for rhel-7?
> 
> Version-Release number of selected component (if applicable):
> 
> libguestfs-1.28.1-1.18.el7

A few notes about this:

(1) virt-v2v in RHEL 6 was a separate upstream package.  It is now
(RHEL >= 7.1) a subpackage of libguestfs.

(2) It requires qemu-kvm-rhev, which is not in base RHEL, so that's
going to cause repoclosure problems.  However I think we should
ignore those -- customers who use virt-v2v will have the necessary
extra subscription to satisfy this dependency.

Hello Rich,

well this is going to fail RTT tests. My recommendation is to push virt-v2v into rhev.

We already have several split rpms (e.g. resource-agents / resource-agents-sap).
We don't want to fight new RC blockers (dependency issues) if we don't have to.

Lubos

NB virt-v2v is also required for Openstack and other layered
products in future (CFME, probably).

This also blocks the libguestfs Errata.

virt-v2v is not a subpackage of libguestfs. But it will be rebuilt during the TPS test. It leads to the error "TPSERROR: virt-v2v-1.28.1-1.18.el7.x86_64.rpm was built by libguestfs-1.28.1-1.18.el7.src.rpm but not included in the file list".

any real reason for qemu-kvm-rhev dependency instead of qemu-kvm?

Hello,

as far as I can see there 4 options:

1) add subpackage to RHEL-7, but it won't be installable unless system is subscribed to RHEV for rhel-7 channels. Which might be a problem for OpenStack/CloudForms customers who didn't purchase RHEV.

2) add subpackage to RH-Common which will result into additional subscription to a channel (if system is not really subscribed into it). RH-Common is probably the best place for it (after rhel-7 :-))

3) add virt-v2v into rhev,clouforms ... instead of rhel. This will increase amounts of errata with each libguestfs release and it will be hard to sync (remember scl-utils?, we've ended up in having it in rhel anyway)

4) add qemu-kvm-rhev and virt-v2v into rhel 7

We'll need program management to decide fate of the rpm. Generally nothing in RHEL should have dependency in layered product. It needs to be done the other way around.


Lubos

Hi Itamar,

well for one reason.

You'd always need to have an async advisory for all of these. 

Which is kind of not easy since most errata for new minor versions (e.g. rhev ...) are typically quarterly updates and you can't mix products in these.

This would have to be handled extra and people are probably not happy to hear it :-) Imagine that you'd have more packages with same issues ... 

Also you'll need to mirror RHEL-6 updates precisely since slip will result into broken updates on customer machines. But I guess you're already doing it qemu-kvm -> qemu-kvm-rhev

Lubos

NB: only the virt-v2v subpackage.

Hello,

I'm for the solution proposed in Comment 10. Please open bugs against respective products.

RHEL-7.1 itself remains unaffected. And we're in Snap 5 phase anyway which wouldn't involve such changes anyway.

Closing as notabug for this product. 

Thanks for understanding

Lubos