Re: [libvirt] [PATCH 00/10] Enable loadable modules for libvirtd
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 :|