On 04/03/2012 06:48 AM, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange(a)redhat.com>
Introduce a set sub-RPMs, one per hypervisor, which can be used
as dependancy targets by applications wishing to pull in the
s/dependancy/dependency/
full stack of packages required for a specific hypervisor. This
avoids the application needing to know what the hypervisor specific
package set is.
ie, applications should not need to know that using the libvirt
Xen hypervisor requires the 'xen' RPM - libvirt should take care
of that knowledge. All the application wants is 'libvirt-daemon-xen'
As I mentioned on the other thread, I'm in favor of this, but it sounded
like DV was a bit worried. Anyone else want to chime in?
There are 5 sub-RPMs:
libvirt-daemon-qemu - non-native TCG based emulators
libvirt-daemon-kvm - native KVM hypervisor
libvirt-daemon-uml - User Mode linux
libvirt-daemon-xen - Xen, either via XenD or libxl
libvirt-daemon-lxc - Linux native containers
When driver modules get turned on, these sub-RPMs will also
gain dependancies on the appropriate driver module .so files
s/dependancies/dependencies/
ACK for the technical aspect, if you don't get outvoted on the design.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org