Home

General

IUS packages are usually based on their Fedora counterparts. Because of that, IUS packages can mostly just follow Fedora packaging guidelines, only deviating when necessary. EPEL packaging guidelines are another useful reference that should be followed if possible. In the course of creating/maintaining an IUS package, if something non-compliant is discovered that came from the Fedora spec file, it should be reported to the Fedora package maintainer to get corrected. This will likely benefit IUS in the future when an even newer package is created from the future Fedora spec file.

Naming

IUS packages must use a different name than the corresponding stock package to prevent unintended upgrades. This alternate name should be determined based on what upstream considers their "major version". Usually this will correspond to a branch in source control. Upstream projects will often document an expected end of life date for such a version. For example, if the foo project claims to support versions 2, 3, and 4 of their software, an appropriate IUS package name would be foo3. This indicates that it will be updated with new 3.x.x versions, but it will never be updated to version 4.x.x. It is also common to see a project support more specific major.minor branches, such as 5.1 and 5.2. This would result in a package name such as foo51, which will always be version 5.1.x, and never update to version 5.2.x.

Some IUS packages also include an extra identifier of a literal "u" at the end, i.e. php72u. This has been used in the past to avoid naming collisions between other packages from EPEL or RHSCL. This identifier is optional.

Safe Replacement

The most significant difference between a normal Fedora or EPEL package is the mechanisms used to achieve safe replacement of stock packages. An IUS safe replacement package has a different name than the stock equivalent, but provides that stock name. For example, to replace a stock package named foo (version 2), a foo3 (version 3) package would include the following line:

Provides:       foo = %{version}-%{release}

Unless foo3 is a noarch package, then it should also contain another architecture-specific provides line.

Provides:       foo%{?_isa} = %{version}-%{release}

The foo3 package will also need to conflict with the stock package name. There are two reasons for this: it must not conflict with the name it provides, and more importantly it will have file conflicts with the stock package and thus cannot be installed at the same time.

Conflicts:      foo < %{version}-%{release}

This results in the follow common lines in most IUS spec files.

Provides:       foo = %{version}-%{release}
Provides:       foo%{?_isa} = %{version}-%{release}
Conflicts:      foo < %{version}-%{release}

These lines will need to be applied to the top level package as well as any subpackages. Remember that any noarch subpackages can omit the architecture-specific provides.