Re: [libvirt] [PATCH] Refactor the libvirt RPM daemon pieces
On Fri, Mar 30, 2012 at 05:53:19PM +0100, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange(a)redhat.com>
There are a number of flaws with our packaging of the libvirtd
daemon:
- Installing 'libvirt' does not install 'qemu-kvm' or 'xen'
etc which are required to actually run the hypervisor in
question
- Installing 'libvirt' pulls in the default configuration
files which may not be wanted & cause problems if installed
inside a guest
like ? configuration files should by definition be under
/etc/libvirt, how can they cause problems to something else ?
- It is not possible to explicitly required all the peices
required to manage a specific hypervisor
yes you require the hypervisor and libvirt, where is the actual
problem ? I don't see how:
Requires: xen
Requires: libvirt
is any worse than
Requires: libvirt-daemon-xen
Requires: libvirt
can you explain ?
This change takes the 'libvirt' RPM and and changes it thus
- libvirt: just a virtual package with dep on libvirt-daemon,
libvirt-daemon-config-network & libvirt-daemon-config-nwfilter
- libvirt-daemon: the libvirt daemon and related pieces
- libvirt-daemon-config-network: the default network config
- libvirt-daemon-config-nwfilter: the network filter configs
- libvirt-docs: the website HTML
So people who used to install libvirt and be all set will now wonder
why x y and z features don't work anymore. I don't see the service to
the users here.
We then introduce some more virtual (empty) packages
- libvirt-daemon-qemu: Deps on libvirt-daemon & 'qemu'
- libvirt-daemon-kvm: Deps on libvirt-daemon & 'qemu-kvm'
- libvirt-daemon-lxc: Deps on libvirt-daemon
- libvirt-daemon-uml: Deps on libvirt-daemon
- libvirt-daemon-xen: Deps on libvirt-daemon & 'xen'
- libvirt-qemu: Deps on libvirt-daemon-qemu &
libvirt-daemon-config-{network,nwfilter}
- libvirt-kvm: Deps on libvirt-daemon-kvm &
libvirt-daemon-config-{network,nwfilter}
- libvirt-lxc: Deps on libvirt-daemon-lxc &
libvirt-daemon-config-{network,nwfilter}
- libvirt-uml: Deps on libvirt-daemon-uml &
libvirt-daemon-config-{network,nwfilter}
- libvirt-xen: Deps on libvirt-daemon-xen & libvirt-daemon-config-network
To be honnest I don't like this, I discover the 20 or so rpms being
built now, most of them empty. If there is a dependancy problem I
would have hoped we could fix this by a different way than a *physical*
empty rpm (they are definitely not virtual as they are built and seems
to be needed for proper setup).
My intent in the future is to turn on the driver modules by
default, at which time 'libvirt-daemon' will cease to include
any specific drivers, instead we'll get libvirt-daemon-driver-XXXX
packages for each driver. The libvirt-daemon-XXX packages will
then pull in each driver that they require.
Then making the split will be fine, but that would depend on the
decision to activate the driver modules, which is not the case now.
It is recommended that applications required a locally installed
libvirtd daemon, use either 'Requires: libvirt-daemon-XXXX' or
'Requires: libvirt-XXX' and *not* "Requires: libvirt-daemon"
or 'Requires: libvirt'
I have a hard time believing that we have a good justification to
break all the "clients" rpms and tools.
I see very little in terms of justification for such a huge change
and pushing this 2 days before the release, I'm very tempted to roll
this back (I didn't see this coming, sorry I was sick, and didn't
monitor properly, still that's a big change and very late for this
release)
At least I don't see any user feeback indicative that such a complete
overhaul was urgent and to be pushed just before the release without
any testing.
NACK from my POV, at least not at this stage !
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/