As mentioned before, we already provide a variety of different installable package sets, both full recommended default and a fine grained minimal set. I don't think we want to keep adding yet more variants, if the recommended default is too large, then pick the individual minimal bits desired. If apps know exactly which subset of libvirt features they want to use, then can pick the individual packages, rather than depend on another metapackage which won't be a perfect fit.

(appologies for the late reply... busy quarter at work.)

You did mention previously that it was possible to depend on a fine-grained set of packages, but I think that's not ideal because the desired set of packages is fairly long, and because it includes dependencies outside of libvirt (i.e. qemu-kvm) which means that downstream packages need to know not only about libvirt's package structure, but about supporting dependencies, and because all of that information would need to be kept in sync across all of the downstream packages where it would be preferable to exclude dependencies that aren't typically relevant on workstations and where additional services are unwanted.

That is, it looks like there's currently only one metapackage for KVM virtualization. It feels like downstream packages are offered only an all-or-nothing option for metapackages, and I would like to find a middle ground.