4:06 a.m.
On Tue, Apr 03, 2012 at 04:22:59PM +0800, Daniel Veillard wrote:
On Mon, Apr 02, 2012 at 08:57:11PM +0100, Daniel P. Berrange wrote:
> For a long timer we've had the ability to build each libvirt
> driver as a loadable module. We have never used this by default
> and as a result it constantly bit-rots.
>
> This series fixes various bugs, and then enables it by default
> in configure. It also makes the PRMs use the loadable modules,
> adding new new sub-RPMs for each module. We can now finally
> install minimal libvirt binaries for each hypervisor.
>
> ie yum install libvirt-kvm
>
> will not pull in Xen libraries!
Okay, I understand the principle, and this sounds good. I'm sorry
for not having caught up the RPM server refactoring patch earlier, I
would have discussed that scenario, and would have avoided me reverting
your patch (I really dislike doing this, I guess that was the first
time I ever did this) but this was IMHO too much change and too early.
I completely agree with the scenario of being able to do
yum install libvirt-kvm
and have libvirt daemon, the bits for the daemon qemu/kvm support,
and related configuration files being pulled in, as well as hooking
up the hypervisor dependency. But to me that means one specific
libvirt-kvm package (tied to the daemon anyway the client should
be agnostic about it), not two !
We should aim at minimizing the number of actual packages while
still providing the needed modularization. So I would expect:
- libvirt (the server and its basic config file)
We can't do that, because changing the base 'libvirt' RPM in this
way will break the upgrade path - we need semantics of doing
'yum install libvirt' to remain unchanged from before.
- libvirt-client (as usual)
- libvirt-devel (as usual)
- libvirt-lock-sanlock (as usual)
- libvirt-python (as usual)
Indeed, there was/is no need to change the client side parts - only
the server side.
- libvirt-kvm (can we merge -kvm and -qemu ?)
It is not desirable to merge them. In Fedora we don't want to force the
install of all the QEMU emulators - we only want to pull in the qemu-kvm
emulator most of the time. If apps depend on libvirt-kvm, they will get
only the KVM stack, while if they depend on libvirt-qemu they will get
the full QEMU stack. In RHEL of course there is no QEMU so that sub-RPM
disappears.
- libvirt-xen
- libvirt-lxc
- libvirt-uml
- libvirt-network (our default network config)
We need each dlopen'd .so file to be in a separate RPM. eg so that when
you install KVM, you don't pull in xen-libs. As well as the hypervisor
drivers though, you have the other pieces like the network/storage/nodedev
drivers. As well as the need to split the virbr0 / nwfilter config files
out, we get a minimum RPM set with actual %file payloads:
- libvirt-daemon - Just the libvirtd daemon, no drivers, no configs
- libvirt-daemon-config-network - Just the virbr0 configs
- libvirt-daemon-config-nwfilter - Just the firewall configs
- 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)
For the sake of backwards compatibility / upgrade path we need:
- libvirt - Virtual RPM, which Requires all of the above RPMs, to
ensure that it pulls in everything that the old libvirt
RPM always had.
Sice it would be really tedious for apps to have to list Requires: on
each libvirt-daemon-driver-XXX module they care about we introduced
(and that would be upgrade-safe if we introduce more sub-drivers),
we need virtual packages:
- libvirt-daemon-YYY - Virtual RPM pulls in the set of drivers
required for a specific hypervisor. One
for each YYY in (uml, qemu, kvm, xen, lxc).
Also depends on the appropriate hypervisr
RPM (eg 'qemu', 'qemu-kvm', 'xen')
- libvirt-YYY - Virtual RPMs to pull in the set of drivers
required for a specific hypervisor, plus
the default config files. One for each
YYY in (uml, qemu, kvm, xen, lxc).
I can see an argument that having 2 sets of virtual packages here is a
little bit overkill. Apps could just have added
Requires: libvirt-daemon-kvm, libvirt-ademon-config-network
if they really want KVM and the default configs. So we could get rid
of one of these virtual package sets without any real loss of flexibility.
I don't see how we can practically eliminate any other sub-RPMS besides
these two, while retained flexibility upon install
for a separate split of the documentation currently in the -devel
package
I'm not so sure it's worth changing but I don't have a strong opinion
Hmm, I didn't notice we had more docs in -devel. I created the -docs RPM
for all the docs that were in the main libvirt RPM - ie the entire copy
of the website. I should also have put all the API docs in there too I
reckon.
Regards,
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 :|