Created attachment 1219459 [details]
qemu.spec patch

The basic plan could be as simple as the attached specfile patch.

Unfortunately the dependencies aren't quite right in this version.
RPM doesn't consider the plugins when calculating dependencies so
although the dependencies are dropped from the qemu-system-* packages,
they are NOT added to the qemu-block-* packages.  Still examining
this.

There is a problem on the upgrade path.  If the user has the 'qemu'
metapackage installed, then they will automatically get all the block
drivers on upgrade.  If the user only has (eg) 'qemu-system-x86' then
on upgrade they will lose all the block drivers in modules.

(In reply to Richard W.M. Jones from comment #1)
>  If the user only has (eg) 'qemu-system-x86' then
> on upgrade they will lose all the block drivers in modules.

That's not only a problem on upgrade - we've encouraged applications to have "Requires: qemu-system-x86" or "Requires: qemu-kvm" as their primary dependancy and we don't want them to all suddenly loose the block drivers on their installs.

Created attachment 1219469 [details]
qemu.spec patch

Improved patch which fixes the problem with dependencies.

(In reply to Daniel Berrange from comment #2)
> (In reply to Richard W.M. Jones from comment #1)
> >  If the user only has (eg) 'qemu-system-x86' then
> > on upgrade they will lose all the block drivers in modules.
> 
> That's not only a problem on upgrade - we've encouraged applications to have
> "Requires: qemu-system-x86" or "Requires: qemu-kvm" as their primary
> dependancy and we don't want them to all suddenly loose the block drivers on
> their installs.

Agreed, but I don't have any better ideas at the moment.

I think the key thing is that everyone should continue to get exactly the same stuff they have today. Users should have to make an explicit change to *not* get some of the modules.

To achieve this we need to use the same trick we did with libvirt when we modularized libvirtd

Change all the 'qemu-system-$ARCH' sub-RPMs into virtual packages which just have some deps

  Requires: qemu-system-$ARCH-emul
  Requires: qemu-module-block-curl
  Requires: qemu-module-block-rbd
  Requires: qemu-module-block-gluster
  Requires: qemu-module-block-dmg
  Requires: qemu-module-block-ssh


All the files that used to be in qemu-system-$ARCH now go into a new qemu-system-$ARCH-emul instead.

That way, people who want to have a super cut-down install of QEMU would install qemu-system-x86-emul only. Everyone else continues to get the same set of block modules they have today.

I agree that would work.

Can I propose another idea: We add the requires to qemu-common
but make them "Recommends".  This allows minimal environments
which don't want the extra dependencies to remove the functionality
while not making the spec too complicated or the list of packages too
long [in your scenario above, what should happen for a user who
just installs qemu-system-x86-emul?]

The only disadvantage would be that we couldn't implement this
in RHEL 7.

(In reply to Richard W.M. Jones from comment #6)
> I agree that would work.
> 
> Can I propose another idea: We add the requires to qemu-common
> but make them "Recommends".  This allows minimal environments
> which don't want the extra dependencies to remove the functionality

I don't think that Recommends as a concept works very well. It means you get every module installed by default and then have to manually uninstall pieces you don't want. This means if you have an application that wants to install only the RBD module, there's no way to express this in deps from your package as AFAICT, there's no way to say "don't install this particular Recommended package" as an RPM dep. With my sub-package proposal, apps can explicitly dep on the exact subset of bits they wish to have.

> while not making the spec too complicated or the list of packages too
> long [in your scenario above, what should happen for a user who
> just installs qemu-system-x86-emul?]

If you only install qemu-system-x86-emul you get just the built-in functionality of QEMU, none of the modules, so the smallest possible install.

> The only disadvantage would be that we couldn't implement this
> in RHEL 7.

I didn't realize that it was intended that qemu-system-*-emul
was a valid installation choice.  In that case we should call it
something more descriptive, such as qemu-system-*-core.

I'll try to modify the patch to do that now.

Created attachment 1219699 [details]
0001-Create-subpackages-for-modularized-qemu-block-driver.patch

Updated patch which implements Dan's plan from comment 5
except the core subpackages are called qemu-system-*-core.

A scratch build is building:
http://koji.fedoraproject.org/koji/taskinfo?taskID=16401212

That looks reasonable to me.

I had a play with the scratch build (see comment 9).

Upgrades work, automatically installing qemu-block-* and
qemu-system-*-core.

You cannot practically uninstall qemu-block-* without removing
quite a lot of other stuff.  I believe this is because of the
libvirt-daemon-qemu -> qemu dependency (and libguestfs for example
depends on libvirt-daemon-qemu).  So perhaps further subpackaging
of libvirt will be needed also.

Currently there is no "qemu-kvm-core".  Should there be?  The
idea is that qemu-kvm-core would depend on qemu-%{kvm_package}-core
(eg. qemu-system-x86-core on x86_64).

Created attachment 1219828 [details]
0001-Create-subpackages-for-modularized-qemu-block-driver.patch

Updated patch with qemu-kvm-core package.

This is a scratch build if anyone wishes to test it out:

http://koji.fedoraproject.org/koji/taskinfo?taskID=16404695

I tested upgrade path of that scratch build and everything worked ok.

I notice that qemu-kvm does not depend on qemu-kvm-core. I understand why this is not required, but it was a little surprising. No big deal though - if we ever get a reason to have such a dep we can add it later without trouble.

So I think this change is fine to push to rawhide.

Final package will be available here soon:

http://koji.fedoraproject.org/koji/taskinfo?taskID=16449155