On Tue, Apr 03, 2012 at 05:41:57PM +0800, Daniel Veillard wrote:
On Tue, Apr 03, 2012 at 10:06:02AM +0100, Daniel P. Berrange wrote:
On Tue, Apr 03, 2012 at 04:22:59PM +0800, Daniel Veillard wrote:
- libvirt-daemon - Just the libvirtd daemon, no drivers, no configs - libvirt-daemon-config-network - Just the virbr0 configs
let's rename to libvirt-daemon-bridge then !
No, I explicitly chose to have -config' in the name, because this really is just the config files, and we might want to use the name 'libvirt-daemon-bridge' at some point in the future.
- libvirt-daemon-config-nwfilter - Just the firewall configs
and libvirt-daemon-nwfilter
Again, I want config there to ensure that the libvirt-ademon-nwfilter RPM name is availble for future use.
the fact that the rpm contains config files, or .so, or binaries the user should care only of what functionality is provided.
The actual nwfilter functionality is provided in the libvirt-daemon RPM, so to suggest they need to use libvirt-daemon-nwfilter is misleading - this is only some default config files which apps do not need to use if they don't want them - oVirt uses its own configs for example.
If we split it that much then we must make sure that rpm -i libvirt-daemon-nwfilter will actually restart the server in the %post (and true for most of the others package, may turn into a challenge when installing 4 extension package and we want to avoid restarting the server 4 times !)
In the re-post I did, I use %posttrans script to ensure it is restarted once, at the end of the transaction.
- libvirt-daemon-driver-XXX - Contains the dlopen'd modules per driver or sub-driver. One for each XXX in: (uml, qemu, xen, lxc, storage, network, nwfilter, interface, nodedev, secrets)
this is what I dislike, I would prefer to see libvirt-kvm and libvirt-daemon-driver-kvm to be merged (and hence my question about qemu and kvm because the .so would be shared I assume) unless there is a good story for having only the .so in the rpm that's the part I really reacted to when I made my tentative build for the release and that looks way to intricate to my taste.
It is not possible to merge these to. For backwards compatibility, we need 'libvirt' to depend on 'libvirt-daemon-driver-qemu'. We do *not*, however, want 'libvirt' to pull in 'qemu' itself. It becomes clear when you consider what the entry points for application dependancies are: /---> libvirt --------+---------> libvirt-daemon | | ^ | | | | \---------> libvirt-daemon-driver-qemu | | | +---> libvirt-daemon-qemu ------------+--|------> qemu | | +---> libvirt-daemon-kvm ----------------+------> qemu-kvm | App Choice So 'yum install libvirt', does *not* pull in 'qemu', 'qemu-kvm' or 'xen' If we merged the packages as you describe, we'd end up with /---> libvirt --------+---------> libvirt-daemon | | ^ | \-------------\ | | | | | | | V | |----------------------------|--> libvirt-daemon-driver-qemu ---> qemu | | | \------\ | | | V |-------------------------------> libvirt-daemon-driver-qemu ---> qemu-kvm | App Choice So, 'yum install libvirt' would end up pulling in every single hypervisor we support (qemu, qemu-kvm, xen), which is not at all what we want. Separating the libvirt-daemon-XXX packages from the libvirt-daemon-driver-XXX packages is key to achieving the goal of minimising install footprint, while maintaining backwards compatibility with existing RPM deps. Rgards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|