Fedora.next Per-Product Configuration Packaging
This is an interim solution for Fedora 21 only. Work is in progress for Fedora 22 to simplify this using the new advanced dependencies available in RPM 4.11 and later
Goals
In the Fedora.next world, we will have a set of curated Fedora Products as well as the availability of classic Fedora. Historically, we have maintained a single set of configuration defaults for all Fedora installs, but different target use-cases have different needs. The goal of this document is to set out the guidelines for creating per-Product configuration defaults.
We want to ensure that all packages have sensible defaults for whichever Product on which they are installed, while also avoiding situations where users would have some packages installed with one Product's defaults and some packages with another.
Definitions
Fedora.next: Umbrella term for planning Fedora's future. Currently covering the creation of the Fedora Products, Fedora Base Design and Fedora Environments and Stacks.
$PRODUCT: One of the Fedora.next Product deliverables, currently "cloud", "server" and "workstation".
yum/dnf: Package managers for Fedora used for installing and updating software.
Sub-package definition
Only packages whose defaults differ between Fedora Products are required to follow these instructions. Packages whose configuration is the same for all products can simply install the config files as they normally would.
Requirements
- All packages must have a global default configuration. This configuration will be used whenever a Product-specific default configuration is not required. (For example, if a non-Product install is in use or only Fedora Cloud has a custom configuration and Fedora Workstation was installed).
- Any package that requires a per-product default configuration must provide a sub-package containing that configuration.
- Such packages must "Requires: foo-config" which will be provided by the configuration sub-package.
- Any package that requires a configuration that differs between Products must obtain permission from that Product's Working Group before packaging it.
Global Default Configuration
- The global default configuration must be specified by a sub-package named "foo-config-standard", where foo is the base package name.
- The global default configuration sub-package must "Requires: foo = %{version}-%{release}" (or appropriate variant including epoch)
- The global default configuration sub-package must include a virtual "Provides: foo-config"
- The global default configuration sub-package must explicitly "Conflicts: system-release-$PRODUCT" for all Products for which there exists a separate configuration.
- The global default configuration sub-package must explicitly "Conflicts: foo-config-$PRODUCT" for all Products for which there exists a separate configuration.
Per-Product Default Configuration
- For each Product requiring a unique default configuration, the packager must provide a sub-package named "foo-config-$PRODUCT", where foo is the base package name and $PRODUCT is the Fedora Product in question. If the global default is sufficient, the packager must not create a Product-specific sub-package.
- Each Product sub-package must include a virtual "Provides: foo-config".
- Each Product sub-package must "Requires: foo = %{version}-%{release}" (or appropriate variant including epoch)
- Each Product sub-package must "Requires: system-release-$PRODUCT", for the matching Product.
- Each Product sub-package must explicitly "Conflicts: foo-config-standard"
- Each Product sub-package must explicitly "Conflicts: foo-config-$PRODUCT" for all other Products for which there exists a separate configuration.
RPM does not currently have the ability to provide separate installroots for different subpackages. You will need to create separate config files for each product in the installroot and symlink them in the %post section for that Product
Example (firewalld)
We will assume for the sake of demonstration that firewalld will need a custom configuration for Fedora Server and Fedora Workstation, but that Fedora Cloud will not require any changes from the global default.
Name: firewalld
Version: 0.3.10
Release: 1{?dist}
Requires: firewalld-config
%package config-standard
Summary: Firewalld standard configuration settings
Provides: firewalld-config
Requires: firewalld = %{version}-%{release}
Conflicts: system-release-server
Conflicts: firewalld-config-server
Conflicts: system-release-workstation
Conflicts: firewalld-config-workstation
%package config-server
Summary: Firewalld server configuration settings
Provides: firewalld-config
Requires: firewalld = %{version}-%{release}
Requires: system-release-server
Conflicts: firewalld-config-workstation
Conflicts: firewalld-config-standard
%package config-workstation
Summary: Firewalld workstation configuration settings
Provides: firewalld-config
Requires: firewalld = %{version}-%{release}
Requires: system-release-workstation
Conflicts: firewalld-config-server
Conflicts: firewalld-config-standard
%files config-standard
%ghost %config(noreplace) %{_sysconfdir}/firewalld.conf
%config(noreplace) %{_sysconfdir}/firewalld-standard.conf
%files config-server
%ghost %config(noreplace) %{_sysconfdir}/firewalld.conf
%config(noreplace) %{_sysconfdir}/firewalld-server.conf
%files config-workstation
%ghost %config(noreplace) %{_sysconfdir}/firewalld.conf
%config(noreplace) %{_sysconfdir}/firewalld-workstation.conf
%post config-standard
if [ $1 -eq 1 ]; then
rm -f %{_sysconfdir}/firewalld/firewalld.conf
ln -sf %{_sysconfdir}/firewalld/firewalld-standard.conf %{_sysconfdir}/firewalld/firewalld.conf
fi
%post config-server
if [ $1 -eq 1 ]; then
rm -f %{_sysconfdir}/firewalld/firewalld.conf
ln -sf %{_sysconfdir}/firewalld/firewalld-server.conf %{_sysconfdir}/firewalld/firewalld.conf
fi
%post config-workstation
if [ $1 -eq 1 ]; then
rm -f %{_sysconfdir}/firewalld/firewalld.conf
ln -sf %{_sysconfdir}/firewalld/firewalld-workstation.conf %{_sysconfdir}/firewalld/firewalld.conf
fi
Reasoning
The configuration sub-packages Requires: the main package in order to guarantee that they always update together (since the reverse dependency is not versioned).
The version comparison algorithm used by yum will attempt to resolve the dependencies through whichever one best matches the Requires/Conflicts or whichever one will install the fewest dependencies. This should result in the appropriate Product configuration being installed or the standard configuration as the fallback.