(Drop versioning. It's unnecessary and confusing. Change to foo-config-standard) |
(Fix mistake with default virtual provides.) |
||
Line 21: | Line 21: | ||
* The global default configuration <b>must</b> be specified by a sub-package named "foo-config-standard", where foo is the base package name. | * The global default configuration <b>must</b> be specified by a sub-package named "foo-config-standard", where foo is the base package name. | ||
* The global default configuration sub-package <b>must</b> "Requires: foo = %{version}-%{release}" (or appropriate variant including epoch) | * The global default configuration sub-package <b>must</b> "Requires: foo = %{version}-%{release}" (or appropriate variant including epoch) | ||
* The global default configuration sub-package <b>must</b> include a virtual "Provides: foo-config" | |||
* The global default configuration sub-package <b>must</b> explicitly "Conflicts: fedora-release-$PRODUCT" for all Products for which there exists a separate configuration. | * The global default configuration sub-package <b>must</b> explicitly "Conflicts: fedora-release-$PRODUCT" for all Products for which there exists a separate configuration. | ||
* The global default configuration sub-package <b>must</b> explicitly "Conflicts: foo-config-$PRODUCT" for all Products for which there exists a separate configuration. | * The global default configuration sub-package <b>must</b> explicitly "Conflicts: foo-config-$PRODUCT" for all Products for which there exists a separate configuration. | ||
Line 46: | Line 47: | ||
%package config-standard | %package config-standard | ||
Requires: firewalld = %{version}-%{release} | Requires: firewalld = %{version}-%{release} | ||
Provides: firewalld-config | |||
Conflicts: fedora-release-server | Conflicts: fedora-release-server | ||
Conflicts: firewalld-config-server | Conflicts: firewalld-config-server |
Revision as of 18:11, 30 June 2014
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
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
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.
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: fedora-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: fedora-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.
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 Requires: firewalld = %{version}-%{release} Provides: firewalld-config Conflicts: fedora-release-server Conflicts: firewalld-config-server Conflicts: fedora-release-workstation Conflicts: firewalld-config-workstation %package config-server Provides: firewalld-config Requires: firewalld = %{version}-%{release} Requires: fedora-release-server Conflicts: firewalld-config-workstation Conflicts: firewalld-config-standard %package config-workstation Provides: firewalld-config = 1.0 Requires: firewalld = %{version}-%{release} Requires: fedora-release-workstation Conflicts: firewalld-config-server Conflicts: firewalld-config-standard
Reasoning
The reason for the virtual versioning of the config packages (2.0 for the global default and 1.0 for the per-Product default) is to help ensure that the yum dependency solver will prefer to choose the global default foo-config rather than cascading the installation of one of the fedora-release-$PRODUCT packages.
Similarly, we are using foo-config for the global default rather than foo-config-global so that the dnf dependency solver will select the shorter name instead of picking the lexicographically first config option (which would usually be foo-config-cloud if it exists).
The configuration sub-packages Requires: the main package in order to guarantee that they always update together (since the reverse dependency is not versioned).