[libvirt] [PATCH] Refactor the libvirt RPM daemon pieces
From: "Daniel P. Berrange" <berrange@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 - It is not possible to explicitly required all the peices required to manage a specific hypervisor 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 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 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. 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' * libvirt.spec.in: Refactor RPMs * docs/packaging.html.in, docs/sitemap.html.in: Document new RPM split rationale --- docs/packaging.html.in | 106 ++++++++++ docs/sitemap.html.in | 4 + libvirt.spec.in | 512 +++++++++++++++++++++++++++++++++++++----------- 3 files changed, 505 insertions(+), 117 deletions(-) create mode 100644 docs/packaging.html.in In v2: - Split libvirt-daemon-configs into libvirt-daemon-config-network and libvirt-daemon-config-nwfilter - Fix ordering of QEMU/KVM bits - Don't install nwfilter configs if the driver is turned off - Enable nwfilter for LXC/UML drivers explicitly, not just KVM - Fix docs typos - Make all %files sections conditional Tested build on F17 and RHEL-6.3 diff --git a/docs/packaging.html.in b/docs/packaging.html.in new file mode 100644 index 0000000..0adffd3 --- /dev/null +++ b/docs/packaging.html.in @@ -0,0 +1,106 @@ +<?xml version="1.0"?> +<html> + <body> + <h1>Distribution packaging</h1> + + <ul id="toc"></ul> + + <p> + This page describes the rationale behind the libvirt distribution +packaging in RPM format. The RPM specfile provided with libvirt targets +all Fedora and RHEL releases. It is split up into a number of sub-RPMs +in order to facilitate minimal installations, targetting specific +feature sets. + </p> + + <h2><a name="real">Real packages</a></h2> + + <p> + The so called "real" packages provide the actual file payloads + related to libvirt. If very specific / targetted functionality + is required, then applications can depend on one or more of these + real packages. + </p> + + <dl> + <dt>libvirt-client</dt> + <dd>This package provides the main libvirt.so library along with + the virsh command line tool. If a C based application only wants + to be able to manage remote hypervisors, this is all that they + need depend on</dd> + <dt>libvirt-devel</dt> + <dd>This package provides the header files and libraries required + to compile and link C applications using libvirt</dd> + <dt>libvirt-python</dt> + <dd>This package provides the Python binding to the C libraries. + It will pull in the libvirt-client RPM. If a Python application + only wants to be able to manage remote hypervisors, this is all + that they need depend on</dd> + <dt>libvirt-daemon</dt> + <dd>This package provides server side libvirtd daemon, which is + required in order to manage any stateful hypervisors (currently + QEMU, KVM, Xen, LXC and UML).</dd> + <dt>libvirt-daemon-config-network</dt> + <dd>This package provides the standard configuration files for + setting up a NAT based network</dd> + <dt>libvirt-daemon-config-nwfilter</dt> + <dd>This package provides the standard configuration files for + network filter rules for ensuring clean VM traffic.</dd> + </dl> + + <h2><a name="virtual">Virtual packages</a></h2> + + <p> + The virtual packages provide convenient targets for application dependencies to + pull in functionality related to specific hypervisors. Since the packaging of + the <code>libvirt-daemon</code> RPM is expected to change in the future to split + each hypervisor driver out into a separate RPM, applications are strongly + recommended to depend on one of the following virtual packages, instead of + depending directly on <code>libvirt-daemon</code> + </p> + + <dl> + <dt>libvirt</dt> + <dd>This package, simply pulls in every single other server side RPM. + If an application wants to ensure all possible libvirt drivers are installed, + this is what they should depend on</dd> + + <dt>libvirt-daemon-qemu</dt> + <dd>This package pulls in the server side daemon, drivers and the QEMU TCG binaries + required to provide emulation of non-native architectures</dd> + <dt>libvirt-daemon-kvm</dt> + <dd>This package pulls in the server side daemon, drivers and the KVM binaries + required to provide hardware accelerated virtualization of the native + architectures</dd> + <dt>libvirt-daemon-lxc</dt> + <dd>This package pulls in the server side daemon and drivers required to + run native Linux containers</dd> + <dt>libvirt-daemon-uml</dt> + <dd>This package pulls in the server side daemon and drivers required to + run User Mode Linux. The application must still provide the actual + UML binary kernels</dd> + <dt>libvirt-daemon-xen</dt> + <dd>This package pulls in the server side daemon and drivers required to + run guests on the Xen hypervisor.</dd> + + <dt>libvirt-qemu</dt> + <dd>This package pulls in the server side daemon, drivers and the QEMU TCG binaries + required to provide emulation of non-native architectures</dd> + <dt>libvirt-kvm</dt> + <dd>This package pulls in the server side daemon, drivers and the KVM binaries + required to provide hardware accelerated virtualization of the native + architectures</dd> + <dt>libvirt-lxc</dt> + <dd>This package pulls in the server side daemon, drivers and default + configuration files required to run native Linux containers</dd> + <dt>libvirt-uml</dt> + <dd>This package pulls in the server side daemon, drivers and default + configuration files required to run User Mode Linux. The application + must still provide the actual UML binary kernels</dd> + <dt>libvirt-xen</dt> + <dd>This package pulls in the server side daemon, drivers and default + configuration files required to run guests on the Xen hypervisor.</dd> + </dl> + + </body> +</html> diff --git a/docs/sitemap.html.in b/docs/sitemap.html.in index 1de2b20..620c989 100644 --- a/docs/sitemap.html.in +++ b/docs/sitemap.html.in @@ -84,6 +84,10 @@ <a href="hooks.html">Hooks</a> <span>Hooks for system specific management</span> </li> + <li> + <a href="packaging.html">Distribution packaging</a> + <span>Rationale for distribution RPM packaging</span> + </li> </ul> </li> <li> diff --git a/libvirt.spec.in b/libvirt.spec.in index 67f1c33..8730881 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -52,6 +52,14 @@ %define with_libxl 0%{!?_without_libxl:%{server_drivers}} %define with_vmware 0%{!?_without_vmware:%{server_drivers}} +%define with_qemu_tcg %{with_qemu} +# Change if we ever provide qemu-kvm binaries on non-x86 hosts +%ifarch %{ix86} x86_64 +%define with_qemu_kvm %{with_qemu} +%else +%define with_qemu_kvm 0 +%endif + # Then the hypervisor drivers that talk via a native remote protocol %define with_phyp 0%{!?_without_phyp:1} %define with_esx 0%{!?_without_esx:1} @@ -125,8 +133,10 @@ # RHEL-5 has restricted QEMU to x86_64 only and is too old for LXC %if 0%{?rhel} == 5 +%define with_qemu_tcg 0 %ifnarch x86_64 %define with_qemu 0 +%define with_qemu_kvm 0 %endif %define with_lxc 0 %endif @@ -134,8 +144,10 @@ # RHEL-6 has restricted QEMU to x86_64 only, stopped including Xen # on all archs. Other archs all have LXC available though %if 0%{?rhel} >= 6 +%define with_qemu_tcg 0 %ifnarch x86_64 %define with_qemu 0 +%define with_qemu_kvm 0 %endif %define with_xen 0 %endif @@ -206,10 +218,13 @@ %define with_storage_disk 0 %endif -%if %{with_qemu} +%if %{with_qemu} || %{with_lxc} || %{with_uml} %define with_nwfilter 0%{!?_without_nwfilter:%{server_drivers}} # Enable libpcap library %define with_libpcap 0%{!?_without_libpcap:%{server_drivers}} +%endif + +%if %{with_qemu} %define with_macvtap 0%{!?_without_macvtap:%{server_drivers}} # numad is used to manage the CPU placement dynamically, @@ -268,109 +283,22 @@ Source: http://libvirt.org/sources/libvirt-%{version}.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root URL: http://libvirt.org/ -# All runtime requirements for the libvirt package (runtime requrements -# for subpackages are listed later in those subpackages) - -# The client side, i.e. shared libs and virsh are in a subpackage -Requires: %{name}-client = %{version}-%{release} - -# Used by many of the drivers, so turn it on whenever the -# daemon is present %if %{with_libvirtd} -# for modprobe of pci devices -Requires: module-init-tools -# for /sbin/ip & /sbin/tc -Requires: iproute -%if %{with_avahi} -Requires: avahi-libs -%endif -%endif +Requires: libvirt-daemon = %{version}-%{release} %if %{with_network} -Requires: dnsmasq >= 2.41 -Requires: radvd -%endif -%if %{with_network} || %{with_nwfilter} -Requires: iptables -Requires: iptables-ipv6 +Requires: libvirt-daemon-config-network = %{version}-%{release} %endif %if %{with_nwfilter} -Requires: ebtables -%endif -# needed for device enumeration -%if %{with_hal} -Requires: hal -%endif -%if %{with_udev} -Requires: udev >= 145 -%endif -%if %{with_polkit} -%if 0%{?fedora} >= 12 || 0%{?rhel} >=6 -Requires: polkit >= 0.93 -%else -Requires: PolicyKit >= 0.6 -%endif -%endif -%if %{with_storage_fs} -Requires: nfs-utils -# For mkfs -Requires: util-linux-ng -# For pool-build probing for existing pools -BuildRequires: libblkid-devel >= 2.17 -# For glusterfs -%if 0%{?fedora} >= 11 -Requires: glusterfs-client >= 2.0.1 -%endif -%endif -%if %{with_qemu} -# From QEMU RPMs -Requires: /usr/bin/qemu-img -# For image compression -Requires: gzip -Requires: bzip2 -Requires: lzop -Requires: xz -%else -%if %{with_xen} -# From Xen RPMs -Requires: /usr/sbin/qcow-create -%endif -%endif -%if %{with_storage_lvm} -# For LVM drivers -Requires: lvm2 -%endif -%if %{with_storage_iscsi} -# For ISCSI driver -Requires: iscsi-initiator-utils -%endif -%if %{with_storage_disk} -# For disk driver -Requires: parted -Requires: device-mapper -%endif -%if %{with_storage_mpath} -# For multipath support -Requires: device-mapper -%endif -%if %{with_cgconfig} -Requires: libcgroup -%endif -%ifarch %{ix86} x86_64 ia64 -# For virConnectGetSysinfo -Requires: dmidecode +Requires: libvirt-daemon-config-nwfilter = %{version}-%{release} %endif -# For service management -%if %{with_systemd} -Requires(post): systemd-units -Requires(post): systemd-sysv -Requires(preun): systemd-units -Requires(postun): systemd-units -%endif -%if %{with_numad} -Requires: numad +# XXX when we turn on driver modules, we need to add +# deps on each driver (Requires: libvirt-daemon-drv-qemu) %endif +Requires: libvirt-docs = %{version}-%{release} +Requires: libvirt-client = %{version}-%{release} -# All build-time requirements +# All build-time requirements. Run-time requirements are +# listed against each sub-RPM %if 0%{?enable_autotools} BuildRequires: autoconf BuildRequires: automake @@ -537,6 +465,279 @@ Libvirt is a C toolkit to interact with the virtualization capabilities of recent versions of Linux (and other OSes). The main package includes the libvirtd server exporting the virtualization support. +%package docs +Summary: Documentation for libvirt library and daemon +Group: Development/Libraries + +%description docs +Copy of the libvirt website documentation + +%if %{with_libvirtd} +%package daemon +Summary: Server side daemon and supporting files for libvirt library +Group: Development/Libraries + +# All runtime requirements for the libvirt package (runtime requrements +# for subpackages are listed later in those subpackages) + +# The client side, i.e. shared libs and virsh are in a subpackage +Requires: %{name}-client = %{version}-%{release} + +# Used by many of the drivers, so turn it on whenever the +# daemon is present +%if %{with_libvirtd} +# for modprobe of pci devices +Requires: module-init-tools +# for /sbin/ip & /sbin/tc +Requires: iproute +%if %{with_avahi} +Requires: avahi-libs +%endif +%endif +%if %{with_network} +Requires: dnsmasq >= 2.41 +Requires: radvd +%endif +%if %{with_network} || %{with_nwfilter} +Requires: iptables +Requires: iptables-ipv6 +%endif +%if %{with_nwfilter} +Requires: ebtables +%endif +# needed for device enumeration +%if %{with_hal} +Requires: hal +%endif +%if %{with_udev} +Requires: udev >= 145 +%endif +%if %{with_polkit} +%if 0%{?fedora} >= 12 || 0%{?rhel} >=6 +Requires: polkit >= 0.93 +%else +Requires: PolicyKit >= 0.6 +%endif +%endif +%if %{with_storage_fs} +Requires: nfs-utils +# For mkfs +Requires: util-linux-ng +# For pool-build probing for existing pools +BuildRequires: libblkid-devel >= 2.17 +# For glusterfs +%if 0%{?fedora} >= 11 +Requires: glusterfs-client >= 2.0.1 +%endif +%endif +%if %{with_qemu} +# From QEMU RPMs +Requires: /usr/bin/qemu-img +# For image compression +Requires: gzip +Requires: bzip2 +Requires: lzop +Requires: xz +%else +%if %{with_xen} +# From Xen RPMs +Requires: /usr/sbin/qcow-create +%endif +%endif +%if %{with_storage_lvm} +# For LVM drivers +Requires: lvm2 +%endif +%if %{with_storage_iscsi} +# For ISCSI driver +Requires: iscsi-initiator-utils +%endif +%if %{with_storage_disk} +# For disk driver +Requires: parted +Requires: device-mapper +%endif +%if %{with_storage_mpath} +# For multipath support +Requires: device-mapper +%endif +%if %{with_cgconfig} +Requires: libcgroup +%endif +%ifarch %{ix86} x86_64 ia64 +# For virConnectGetSysinfo +Requires: dmidecode +%endif +# For service management +%if %{with_systemd} +Requires(post): systemd-units +Requires(post): systemd-sysv +Requires(preun): systemd-units +Requires(postun): systemd-units +%endif +%if %{with_numad} +Requires: numad +%endif + +%description daemon +Server side daemon required to manage the virtualization capabilities +of recent versions of Linux. Requires a hypervisor specific sub-RPM +for specific drivers. + +%if %{with_network} +%package daemon-config-network +Summary: Default configuration files for the libvirtd daemon +Group: Development/Libraries + +Requires: libvirt-daemon = %{version}-%{release} + +%description daemon-config-network +Default configuration files for setting up NAT based networking +%endif + +%if %{with_nwfilter} +%package daemon-config-nwfilter +Summary: Network filter configuration files for the libvirtd daemon +Group: Development/Libraries + +Requires: libvirt-daemon = %{version}-%{release} + +%description daemon-config-nwfilter +Network filter configuration files for cleaning guest traffic +%endif + +# XXX when we turn on driver modules, we will need to +# create daemon-drv-XXX sub-RPMs and add them as deps +# to all of the following daemon-XXX RPMs + +%if %{with_qemu_tcg} +%package daemon-qemu +Summary: Server side daemon & driver required to run QEMU guests +Group: Development/Libraries + +Requires: libvirt-daemon = %{version}-%{release} +Requires: qemu + +%description daemon-qemu +Server side daemon and driver required to manage the virtualization +capabilities of the QEMU TCG emulators + +%package qemu +Summary: Server side daemon, driver & default configs required to run QEMU guests +Group: Development/Libraries + +Requires: libvirt-daemon-qemu = %{version}-%{release} +Requires: libvirt-daemon-config-network = %{version}-%{release} +Requires: libvirt-daemon-config-nwfilter = %{version}-%{release} + +%description qemu +Server side daemon, driver and default network & firewall configs +required to manage the virtualization capabilities of QEMU. +%endif + + +%if %{with_qemu_kvm} +%package daemon-kvm +Summary: Server side daemon & driver required to run QEMU guests +Group: Development/Libraries + +Requires: libvirt-daemon = %{version}-%{release} +Requires: qemu-kvm + +%description daemon-kvm +Server side daemon and driver required to manage the virtualization +capabilities of the QEMU KVM hypervisor + +%package kvm +Summary: Server side daemon, driver & default configs required to run KVM guests +Group: Development/Libraries + +Requires: libvirt-daemon-kvm = %{version}-%{release} +Requires: libvirt-daemon-config-network = %{version}-%{release} +Requires: libvirt-daemon-config-nwfilter = %{version}-%{release} + +%description kvm +Server side daemon, driver and default network & firewall configs +required to manage the virtualization capabilities of KVM. +%endif + + +%if %{with_lxc} +%package daemon-lxc +Summary: Server side daemon & driver required to run LXC guests +Group: Development/Libraries + +Requires: libvirt-daemon = %{version}-%{release} + +%description daemon-lxc +Server side daemon and driver required to manage the virtualization +capabilities of LXC + +%package lxc +Summary: Server side daemon, driver & default configs required to run LXC guests +Group: Development/Libraries + +Requires: libvirt-daemon-lxc = %{version}-%{release} +Requires: libvirt-daemon-config-network = %{version}-%{release} +Requires: libvirt-daemon-config-nwfilter = %{version}-%{release} + +%description lxc +Server side daemon, driver and default network & firewall configs +required to manage the virtualization capabilities of LXC. +%endif + + +%if %{with_uml} +%package daemon-uml +Summary: Server side daemon & driver required to run UML guests +Group: Development/Libraries + +Requires: libvirt-daemon = %{version}-%{release} +# There are no UML kernel RPMs in Fedora/RHEL to depend on. + +%description daemon-uml +Server side daemon and driver required to manage the virtualization +capabilities of UML + +%package uml +Summary: Server side daemon, driver & default configs required to run UML guests +Group: Development/Libraries + +Requires: libvirt-daemon-uml = %{version}-%{release} +Requires: libvirt-daemon-config-network = %{version}-%{release} +Requires: libvirt-daemon-config-nwfilter = %{version}-%{release} + +%description uml +Server side daemon, driver and default network & firewall configs +required to manage the virtualization capabilities of UML. +%endif + + +%if %{with_xen} +%package daemon-xen +Summary: Server side daemon & driver required to run XEN guests +Group: Development/Libraries + +Requires: libvirt-daemon = %{version}-%{release} +Requires: xen + +%description daemon-xen +Server side daemon and driver required to manage the virtualization +capabilities of XEN + +%package xen +Summary: Server side daemon, driver & default configs required to run XEN guests +Group: Development/Libraries + +Requires: libvirt-daemon-xen = %{version}-%{release} +Requires: libvirt-daemon-config-network = %{version}-%{release} + +%description xen +Server side daemon, driver and default network & firewall configs +required to manage the virtualization capabilities of Xen. +%endif +%endif + %package client Summary: Client side library and utilities of the libvirt library Group: Development/Libraries @@ -582,7 +783,7 @@ Group: Development/Libraries Requires: sanlock >= 1.8 #for virt-sanlock-cleanup require augeas Requires: augeas -Requires: %{name} = %{version}-%{release} +Requires: %{name}-daemon = %{version}-%{release} %description lock-sanlock Includes the Sanlock lock manager plugin for the QEMU @@ -884,6 +1085,12 @@ rm -rf $RPM_BUILD_ROOT%{_sysconfdir}/logrotate.d/libvirtd.lxc rm -rf $RPM_BUILD_ROOT%{_sysconfdir}/logrotate.d/libvirtd.uml %endif +mv $RPM_BUILD_ROOT%{_datadir}/doc/libvirt-%{version} $RPM_BUILD_ROOT%{_datadir}/doc/libvirt-docs-%{version} + +%if ! %{with_nwfilter} +rm -rf $RPM_BUILD_ROOT%{_sysconfdir}/libvirt/nwfilter +%endif + %clean rm -fr %{buildroot} @@ -898,7 +1105,8 @@ do done make check -%pre +%if %{with_libvirtd} +%pre daemon %if 0%{?fedora} >= 12 || 0%{?rhel} >= 6 # Normally 'setup' adds this in /etc/passwd, but this is # here for case of upgrades from earlier Fedora/RHEL. This @@ -910,22 +1118,9 @@ getent passwd qemu >/dev/null || \ -c "qemu user" qemu %endif -%post +%post daemon -%if %{with_libvirtd} %if %{with_network} -# We want to install the default network for initial RPM installs -# or on the first upgrade from a non-network aware libvirt only. -# We check this by looking to see if the daemon is already installed -if ! /sbin/chkconfig libvirtd && test ! -f %{_sysconfdir}/libvirt/qemu/networks/default.xml -then - UUID=`/usr/bin/uuidgen` - sed -e "s,</name>,</name>\n <uuid>$UUID</uuid>," \ - < %{_datadir}/libvirt/networks/default.xml \ - > %{_sysconfdir}/libvirt/qemu/networks/default.xml - ln -s ../default.xml %{_sysconfdir}/libvirt/qemu/networks/autostart/default.xml -fi - # All newly defined networks will have a mac address for the bridge # auto-generated, but networks already existing at the time of upgrade # will not. We need to go through all the network configs, look for @@ -991,8 +1186,8 @@ fi %endif %endif -%preun %if %{with_libvirtd} +%preun daemon %if %{with_systemd} if [ $1 -eq 0 ] ; then # Package removal, not upgrade @@ -1007,8 +1202,8 @@ fi %endif %endif -%postun %if %{with_libvirtd} +%postun daemon %if %{with_systemd} /bin/systemctl daemon-reload >/dev/null 2>&1 || : if [ $1 -ge 1 ] ; then @@ -1019,6 +1214,20 @@ fi %endif %if %{with_libvirtd} +%if %{with_network} +%post daemon-config-network +if test $1 -eq 1 && test ! -f %{_sysconfdir}/libvirt/qemu/networks/default.xml ; then + UUID=`/usr/bin/uuidgen` + sed -e "s,</name>,</name>\n <uuid>$UUID</uuid>," \ + < %{_datadir}/libvirt/networks/default.xml \ + > %{_sysconfdir}/libvirt/qemu/networks/default.xml + ln -s ../default.xml %{_sysconfdir}/libvirt/qemu/networks/autostart/default.xml +fi +%endif +%endif + + +%if %{with_libvirtd} %if %{with_systemd} %triggerun -- libvirt < 0.9.4 %{_bindir}/systemd-sysv-convert --save libvirtd >/dev/null 2>&1 ||: @@ -1064,10 +1273,19 @@ fi /bin/systemctl try-restart libvirt-guests.service >/dev/null 2>&1 || : %endif -%if %{with_libvirtd} %files %defattr(-, root, root) +%files docs +%defattr(-, root, root) +%dir %{_datadir}/doc/libvirt-docs-%{version} +%dir %{_datadir}/doc/libvirt-docs-%{version}/html +%{_datadir}/doc/libvirt-docs-%{version}/html/* + +%if %{with_libvirtd} +%files daemon +%defattr(-, root, root) + %doc AUTHORS ChangeLog.gz NEWS README COPYING.LIB TODO %dir %attr(0700, root, root) %{_sysconfdir}/libvirt/ @@ -1078,7 +1296,6 @@ fi %endif %dir %attr(0700, root, root) %{_sysconfdir}/libvirt/nwfilter/ -%{_sysconfdir}/libvirt/nwfilter/*.xml %{_sysconfdir}/rc.d/init.d/libvirtd %if %{with_systemd} @@ -1190,6 +1407,67 @@ rm -f $RPM_BUILD_ROOT%{_sysconfdir}/sysctl.d/libvirtd %{_mandir}/man8/libvirtd.8* %doc docs/*.xml + +%if %{with_network} +%files daemon-config-network +%defattr(-, root, root) +%endif + +%if %{with_nwfilter} +%files daemon-config-nwfilter +%defattr(-, root, root) +%{_sysconfdir}/libvirt/nwfilter/*.xml +%endif + +%if %{with_qemu_tcg} +%files daemon-qemu +%defattr(-, root, root) +%endif + +%if %{with_qemu_kvm} +%files daemon-kvm +%defattr(-, root, root) +%endif + +%if %{with_lxc} +%files daemon-lxc +%defattr(-, root, root) +%endif + +%if %{with_uml} +%files daemon-uml +%defattr(-, root, root) +%endif + +%if %{with_xen} +%files daemon-xen +%defattr(-, root, root) +%endif + +%if %{with_qemu_tcg} +%files qemu +%defattr(-, root, root) +%endif + +%if %{with_qemu_kvm} +%files kvm +%defattr(-, root, root) +%endif + +%if %{with_lxc} +%files lxc +%defattr(-, root, root) +%endif + +%if %{with_uml} +%files uml +%defattr(-, root, root) +%endif + +%if %{with_xen} +%files xen +%defattr(-, root, root) +%endif %endif %if %{with_sanlock} -- 1.7.7.6
On 03/30/2012 12:53 PM, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange@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 - It is not possible to explicitly required all the peices required to manage a specific hypervisor
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
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
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.
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 did a successful "make rpm" on Fedora 16, which resulted in 21 rpm's (including the source rpm). When I tried to update using rpm -U, I was told that I didn't have the required "qemu" and "xen" packages installed (not surprising, since I never use them). Installing qemu cost 52MB on my disk, and xen another 27. This isn't a bother to me, but I suppose it could be for someone who was trying to make images as small as possible. On the other hand, that person will just need to start using the "libvirt-kvm" package instead of "libvirt". I guess the only concern I have left is whether or not this change in package grouping will create any unsavory situations when somebody upgrades. (there are a few lines in the docs that are still > 80 characters (for some reason, all of them end in "binaries")). Beyond that, it all looks good to me and I'm willing to give my ACK for what it's worth, but I think it would be a "very good idea" to have it looked over by someone with a better knowledge of specfiles than mine.
On Fri, Mar 30, 2012 at 03:00:03PM -0400, Laine Stump wrote:
On 03/30/2012 12:53 PM, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange@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 - It is not possible to explicitly required all the peices required to manage a specific hypervisor
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
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
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.
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 did a successful "make rpm" on Fedora 16, which resulted in 21 rpm's (including the source rpm).
When I tried to update using rpm -U, I was told that I didn't have the required "qemu" and "xen" packages installed (not surprising, since I never use them). Installing qemu cost 52MB on my disk, and xen another 27. This isn't a bother to me, but I suppose it could be for someone who was trying to make images as small as possible. On the other hand, that person will just need to start using the "libvirt-kvm" package instead of "libvirt".
I assume that is because you did 'rpm -Uvh *.rpm', which means it would have included libvirt-qemu and libvirt-xen which in turn dep on 'qemu' and 'xen' respectively. If you had merely asked to install 'libvirt', it would not have required libvirt-qemu or libvirt-xen. To clarify the dependancy chain is this: libvirt -> libvirt-daemon, libvirt-config-network, libvirt-config-nwfilter libvirt-daemon-qemu -> libvirt-daemon, qemu libvirt-daemon-kvm -> libvirt-daemon, qemu-kvm libvirt-daemon-xen -> libvirt-daemon, xen libvirt-qemu -> libvirt-daemon-qemu, libvirt-config-network, libvirt-config-nwfilter libvirt-kvm -> libvirt-daemon-kvm, libvirt-config-network, libvirt-config-nwfilter libvirt-xen -> libvirt-daemon-xen, libvirt-config-network Notice there is no direct dep from 'libvirt' to 'qemu' or 'xen', only from the libvirt-qemu RPMs, which are not required by anything else. 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 :|
On 03/30/2012 03:30 PM, Daniel P. Berrange wrote:
On 03/30/2012 12:53 PM, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange@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 - It is not possible to explicitly required all the peices required to manage a specific hypervisor
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
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
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.
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 did a successful "make rpm" on Fedora 16, which resulted in 21 rpm's (including the source rpm).
When I tried to update using rpm -U, I was told that I didn't have the required "qemu" and "xen" packages installed (not surprising, since I never use them). Installing qemu cost 52MB on my disk, and xen another 27. This isn't a bother to me, but I suppose it could be for someone who was trying to make images as small as possible. On the other hand, that person will just need to start using the "libvirt-kvm" package instead of "libvirt". I assume that is because you did 'rpm -Uvh *.rpm', which means it would have included libvirt-qemu and libvirt-xen which in turn dep on 'qemu' and 'xen' respectively. If you had merely asked to install 'libvirt', it would not have required libvirt-qemu or
On Fri, Mar 30, 2012 at 03:00:03PM -0400, Laine Stump wrote: libvirt-xen.
You assume correctly. I had always (incorrectly) assumed that rpm -U would only update the machine rpms that were already installed. I'd never actually checked. So everything with this change seems okay to me.
On 03/30/2012 10:53 AM, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange@redhat.com>
There are a number of flaws with our packaging of the libvirtd daemon:
+ +%if %{with_libvirtd} +%package daemon +Summary: Server side daemon and supporting files for libvirt library +Group: Development/Libraries + +# All runtime requirements for the libvirt package (runtime requrements +# for subpackages are listed later in those subpackages) + +# The client side, i.e. shared libs and virsh are in a subpackage +Requires: %{name}-client = %{version}-%{release} + +# Used by many of the drivers, so turn it on whenever the +# daemon is present +%if %{with_libvirtd}
You've now nested %if %{with_libvirtd} twice; this could be simplified, but cleanups can be saved for another day if we are under the gun to get this out now (is there a cppi equivalent for spec files to help show nesting? Can you even indent %if directives for sanity in a spec file?)
+# for modprobe of pci devices ...
+# For glusterfs +%if 0%{?fedora} >= 11 +Requires: glusterfs-client >= 2.0.1 +%endif +%endif +%if %{with_qemu} +# From QEMU RPMs +Requires: /usr/bin/qemu-img
Should this Requires: be pushed down to libvirt-daemon-qemu...
+# For image compression +Requires: gzip +Requires: bzip2 +Requires: lzop +Requires: xz +%else +%if %{with_xen} +# From Xen RPMs +Requires: /usr/sbin/qcow-create
and this one to libvirt-daemon-kvm? But I can live with them here. ...
+# For virConnectGetSysinfo +Requires: dmidecode +%endif +# For service management +%if %{with_systemd} +Requires(post): systemd-units +Requires(post): systemd-sysv +Requires(preun): systemd-units +Requires(postun): systemd-units
These four requires deal with services, but we already pushed services into libvirt-daemon-config-network; I'm guessing these should be relocated to that section. Or maybe I'm misunderstanding - is it that these enable libvirtd to run as a service, but libvirtd will do nothing to cause interference (like trying to set up the 'default' NAT network at 192.168.122.0) unless you also have the config files? In that case, what you did looks okay.
+%endif +%if %{with_numad} +Requires: numad +%endif + +%description daemon +Server side daemon required to manage the virtualization capabilities +of recent versions of Linux. Requires a hypervisor specific sub-RPM +for specific drivers.
It looks weird to have the %description so far down from the %package with all the Requires in between. But that's cosmetic. I spotted a few things you can clean up, but nothing was a show-stopper to pushing this as-is, so you have my ACK. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Fri, Mar 30, 2012 at 04:40:09PM -0600, Eric Blake wrote:
On 03/30/2012 10:53 AM, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange@redhat.com>
There are a number of flaws with our packaging of the libvirtd daemon:
+ +%if %{with_libvirtd} +%package daemon +Summary: Server side daemon and supporting files for libvirt library +Group: Development/Libraries + +# All runtime requirements for the libvirt package (runtime requrements +# for subpackages are listed later in those subpackages) + +# The client side, i.e. shared libs and virsh are in a subpackage +Requires: %{name}-client = %{version}-%{release} + +# Used by many of the drivers, so turn it on whenever the +# daemon is present +%if %{with_libvirtd}
You've now nested %if %{with_libvirtd} twice; this could be simplified, but cleanups can be saved for another day if we are under the gun to get this out now (is there a cppi equivalent for spec files to help show nesting? Can you even indent %if directives for sanity in a spec file?)
Yes, i'll kill that nesting.
+# for modprobe of pci devices ...
+# For glusterfs +%if 0%{?fedora} >= 11 +Requires: glusterfs-client >= 2.0.1 +%endif +%endif +%if %{with_qemu} +# From QEMU RPMs +Requires: /usr/bin/qemu-img
Should this Requires: be pushed down to libvirt-daemon-qemu...
This is used by the storage driver, which is shared amongst xen, qemu, libxl, lxc & uml hypervisor drivers.
+# For image compression +Requires: gzip +Requires: bzip2 +Requires: lzop +Requires: xz +%else +%if %{with_xen} +# From Xen RPMs +Requires: /usr/sbin/qcow-create
and this one to libvirt-daemon-kvm?
Likewise, shared.
+# For virConnectGetSysinfo +Requires: dmidecode +%endif +# For service management +%if %{with_systemd} +Requires(post): systemd-units +Requires(post): systemd-sysv +Requires(preun): systemd-units +Requires(postun): systemd-units
These four requires deal with services, but we already pushed services into libvirt-daemon-config-network; I'm guessing these should be relocated to that section.
Or maybe I'm misunderstanding - is it that these enable libvirtd to run as a service, but libvirtd will do nothing to cause interference (like trying to set up the 'default' NAT network at 192.168.122.0) unless you also have the config files? In that case, what you did looks okay.
I only pushed the install of the network XML into the daemon-config-network RPM. There is still a '%post daemon' section which deals with the init scrpits which is what these requires are for.
+%endif +%if %{with_numad} +Requires: numad +%endif + +%description daemon +Server side daemon required to manage the virtualization capabilities +of recent versions of Linux. Requires a hypervisor specific sub-RPM +for specific drivers.
It looks weird to have the %description so far down from the %package with all the Requires in between. But that's cosmetic.
This is layout normal practice - it just looks a bit wierd because we have soooo many requires. 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 :|
On Fri, Mar 30, 2012 at 05:53:19PM +0100, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange@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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Tue, Apr 03, 2012 at 01:55:32PM +0800, Daniel Veillard wrote:
On Fri, Mar 30, 2012 at 05:53:19PM +0100, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange@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 ?
The scenario is this: - Fedora 17 LiveCD includes GNOME Boxes by default - GNOME Boxes dependancy on libvirtd pulls in configs - Libvirtd is set to autostart on boot - User boots LiveCD in a virtual machine - LiveCD is given an address in 192.168.122.0/24 - libvirtd in the guest starts and activates the default network config, which has an address 192.168.122.0/24 Kaboom, you now have broken networking in the guest. The second scenario is where libvirt is used by oVirt or OpenStack. They (and many other users) have long complained that they don't want virbr0 to be pulled into their installs. Both of these scenarios mean we need to make it possible to install libvirtd, without providing any of the config files. The reason for splitting the RPM with network vs nwfilter config files, so that some applications (OpenStack) *do* still want the nwfilter config files to be present.
- 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
You would not actually want the 'Requires libvirt' line here at all - that would pull in everything - as it does today. You *only* want the 'libvirt-daemon-xen' RPM, which will pull in just the parts required to run Xen. Much of this split was design to be forward looking to the next change to actually use dlopen'd loadable modules in libvirtd. So the 'libvirt-daemon-xen' RPM will depend on the set of .so libraries required to run Xen. So the difference between the two examples you give is - No longer need to explicitly add a dep on 'xen' in application RPMs - Only the Xen parts of libvirt get installed - not the KVM driver code. This means that auto-probing of the URIs should enable Xen as expected, and not enable KVM.
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.
No you mis-understand. If you do 'yum install libvirt' you get *exactly* the same stuff installed as you have always done. ie you get everything. I absolutely did *not* want to break the upgrade path for people who already have libvirtd installed. People who want a smaller install, would *not* depend on libvirt anymore, but rather one of the hypervisor specific sub-RPMs.
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.
We have not broken anything - that was an absolutely critical goal. The upgrade path is 100% preserved. The new fine-grained RPM installs deps are a opt-in for applications - if they do not want to take advantage of this, they can go on having a dep on 'libvirt' and get no change in behaviour. 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 :|
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Eric Blake -
Laine Stump