On 04/03/2012 08:46 AM, Daniel P. Berrange wrote: >>> I think it is worth it, based on the fact that we get reasonably >>> frequent bug reports that installing libvirt did not install qemu-kvm, >>> or similar. >> >> In practice now we ask people to install 'qemu-kvm' directly >> With the change we ask people to install 'libvirt-kvm' instead, > > Almost. Currently we ask to install 'libvirt' and 'qemu-kvm', > now we just need to install 'libvirt-daemon-kvm'. I think that being able to select one package instead of two is a benefit (the old way requires me to select both 'libvirt' and 'qemu-kvm' before my kvm guests work, the new way says that I want the one package 'libvirt-daemon-kvm' and I get everything needed for kvm guests). > >> I don't see such an huge improvement to be honnest, basically ths means >> that people must select the hypervisor at some point, whether it's >> at the base os install vs. at the libvirt install. I look at it as a stack issue - I know that libvirt is in my stack, and since I want to only interact with libvirt, I _don't_ want to know what lower pieces in the stack also have to be pulled in. Having to manually select 'qemu-kvm' is a violation of the layering. For comparison, if I plan on using stdio, I want to use fopen() and fwrite() and friends from just <stdio.h> - I shouldn't have to care that stdio uses open() and write() and close() from <unistd.h> and other lower-level headers. An application using libvirt should not have to know what lower-level components to pull in, they should just pull in the appropriate libvirt package that meets their needs. -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list