On 03/30/2012 09:22 AM, Daniel P. Berrange wrote:
> From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
>
> NB: this is in response to a Fedora 17 beta blocker bug.
> Currently gnome-boxes depends on 'libvirt' which pulls
> in the default virtual network, which kills networking
> if you install Fedora 17 inside a KVM guest.
>
> 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 and
> libvirt-daemon-configs
> - libvirt-daemon: the libvirt daemon and related pieces
> - libvirt-daemon-configs: the default 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-configs
> - libvirt-kvm: Deps on libvirt-daemon-kvm & libvirt-daemon-configs
> - libvirt-lxc: Deps on libvirt-daemon-lxc & libvirt-daemon-configs
> - libvirt-uml: Deps on libvirt-daemon-uml & libvirt-daemon-configs
> - libvirt-xen: Deps on libvirt-daemon-xen & libvirt-daemon-configs
>
> 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.
I like the modularity of this package setup. There is one difference
with the change described in the final paragraph, though, that will
cause some surprises when it's done:
With the current setup, you can install the "libvirt" package, and it
will just use/present whichever hypervisors happen to be installed on
the machine. With the new setup, if you have qemu-kvm and lxc installed
on the machine, then install "libvirt", you won't get the libvirt driver
for either of these - you'll need to explicitly install libvirt-qemu and
libvirt-lxc. This may cause surprises for people who already have
bootstraps that just install "qemu-kvm" and "libvirt".
Is there a way within the package system to specify something like "If
package X is installed, then also require package libvirt-X"?
> 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 | 100 ++++++++++
> docs/sitemap.html.in | 4 +
> libvirt.spec.in | 474 +++++++++++++++++++++++++++++++++++-------------
> 3 files changed, 456 insertions(+), 122 deletions(-)
> create mode 100644 docs/packaging.html.in
>
> diff --git a/docs/packaging.html.in b/docs/packaging.html.in
> new file mode 100644
> index 0000000..2e4abf7
> --- /dev/null
> +++ b/docs/packaging.html.in
> @@ -0,0 +1,100 @@
> +<?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>Real packages</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.
Several long lines. It would be nice to wrap them to < 80 columns.
> + 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-configs</dt>
> + <dd>This package provides the standard configuration files for setting up a NAT
> + based network, and network filter rules for ensuring clean VM traffic.</dd>
> + </dl>
> +
> + <h2>Virtual packages</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 kenrels</dd>
s/kenrels/kernels
> + <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 kenrels</dd>
Okay, okay,
s/kenrels/kernels/g :-)
> + <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..743d43e 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}
qemu_tcg wasn't mentioned anywhere in the documentation or commit log
message. Was this intentional?
(Note after further reading - it looks like qemu_tcg is being used as an
easier-to-differentiate synonym for "qemu" (i.e. software-only qemu), is
that right?)
> +# 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
> @@ -268,109 +280,17 @@ 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
> -%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
> +Requires: libvirt-daemon = %{version}-%{release}
> +Requires: libvirt-daemon-configs = %{version}-%{release}
> +# 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 +457,271 @@ 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.
>
> +%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
> +
> +%package docs
> +Summary: Documentation for libvirt library and daemon
> +Group: Development/Libraries
> +
> +%description docs
> +Copy of the libvirt website documentation
> +
> +%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.
Functionally it probably makes no difference, but I think it would be
better if "%description daemon" was put next to "%package daemon" rather
than having the %package and %description of docs in between. Or is this
grouped in some other way that I missed?
> +
> +%package daemon-configs
> +Summary: Default configuration files for the libvirtd daemon
> +Group: Development/Libraries
> +
> +Requires: libvirt-daemon = %{version}-%{release}
> +
> +%description daemon-configs
> +Default configuration files for setting up NAT based networking
> +and guest network traffic filtering.
> +%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
> +%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
> +%endif
> +
> +%if %{with_qemu_tcg}
> +%description daemon-qemu
> +Server side daemon and driver required to manage the virtualization
> +capabilities of the QEMU TCG emulators
> +%endif
> +
> +%if %{with_qemu_kvm}
> +%description daemon-kvm
> +Server side daemon and driver required to manage the virtualization
> +capabilities of the QEMU KVM hypervisor
> +%endif
These sections also seem to be mixed up. But maybe I'm expecting a
different kind of grouping than you're using.
> +
> +%if %{with_qemu_tcg}
> +%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-configs = %{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 kvm
> +Summary: Server side daemon, driver & default configs required to run KVM guests
> +Group: Development/Libraries
> +
> +Requires: libvirt-daemon-kvm = %{version}-%{release}
> +Requires: libvirt-configs = %{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}
> +Requires: lxc
> +
> +%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-configs = %{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-configs = %{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-configs = %{version}-%{release}
> +
> +%description xen
> +Server side daemon, driver and default network & firewall configs
> +required to manage the virtualization capabilities of Xen.
> +%endif
> +
> %package client
> Summary: Client side library and utilities of the libvirt library
> Group: Development/Libraries
> @@ -582,7 +767,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}
Heh. I was confused for a minute until I saw that a large chunk of the
existing spec was skipped (for a second it looked like you had
libvirt-client Require'ing libvirt-daemon :-))
>
> %description lock-sanlock
> Includes the Sanlock lock manager plugin for the QEMU
> @@ -811,8 +996,7 @@ autoreconf -if
> %{with_packager_version} \
> --with-qemu-user=%{qemu_user} \
> --with-qemu-group=%{qemu_group} \
> - %{init_scripts} \
> - --with-remote-pid-file=%{_localstatedir}/run/libvirtd.pid
> + %{init_scripts}
What's the story with this bit? Is that option included in some other
way that I missed now? Or is it unneeded? Should it be in this patch, or
is it addressing a separate issue?
> make %{?_smp_mflags}
> gzip -9 ChangeLog
>
> @@ -884,6 +1068,8 @@ 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}
> +
> %clean
> rm -fr %{buildroot}
>
> @@ -898,7 +1084,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 +1097,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 +1165,8 @@ fi
> %endif
> %endif
>
> -%preun
> %if %{with_libvirtd}
> +%preun daemon
> %if %{with_systemd}
> if [ $1 -eq 0 ] ; then
> # Package removal, not upgrade
> @@ -1007,8 +1181,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 +1193,20 @@ fi
> %endif
>
> %if %{with_libvirtd}
> +%if %{with_network}
> +%post daemon-configs
> +if [ $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 +1252,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 +1275,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,8 +1386,42 @@ rm -f $RPM_BUILD_ROOT%{_sysconfdir}/sysctl.d/libvirtd
> %{_mandir}/man8/libvirtd.8*
>
> %doc docs/*.xml
> +
> +%files daemon-configs
> +%defattr(-, root, root)
> +%{_sysconfdir}/libvirt/nwfilter/*.xml
> %endif
>
> +%files daemon-qemu
> +%defattr(-, root, root)
> +
> +%files daemon-kvm
> +%defattr(-, root, root)
> +
> +%files daemon-lxc
> +%defattr(-, root, root)
> +
> +%files daemon-uml
> +%defattr(-, root, root)
> +
> +%files daemon-xen
> +%defattr(-, root, root)
> +
> +%files qemu
> +%defattr(-, root, root)
> +
> +%files kvm
> +%defattr(-, root, root)
> +
> +%files lxc
> +%defattr(-, root, root)
> +
> +%files uml
> +%defattr(-, root, root)
> +
> +%files xen
> +%defattr(-, root, root)
> +
> %if %{with_sanlock}
> %files lock-sanlock
> %defattr(-, root, root)
Aside from the above comments everything seems to make sense (for as far
as I understand specfiles :-/), but the real proof I guess will be in
examining the results of builds, and what is pulled in when particular
packages are installed.
One worry about this from the point of view of Fedora is that final beta
deadline is past, and we basically have one chance to get this right. Is
there any way to do this in two steps such that the 1st would be
sufficient to solve Fedora's problem, but be much less intrusive? Or
would the extra step itself just add a bunch more chances for something
to go wrong in the 2nd step, with no real simplification gain in the
first step?
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list