Sometimes a package is intended to be removed from Fedora, but it is kept in Fedora for some additional (often indeterminate) time for various reasons including maintaining backwards compatibility. In order to prevent new packages from depending on such a package, it can be marked as deprecated.
Packages MUST NOT be initially deprecated in any branch other than rawhide (master), the upcoming release branch, if it exists (until the Final Freeze), and EPEL branches.
Prerequisites for deprecation
If nothing in Fedora depends on a package, a maintainer may deprecate it at their leisure. A maintainer (or collection of maintainers) may also deprecate a set of packages together if no package in that set is a dependency of any package outside of that set.
If a package is a dependency of other packages in the distribution (which are not to be deprecated) then deprecation requires a FESCo approved Fedora change. A packager SHOULD communicate package deprecation to other maintainers, preferably via the devel or devel-announce mailing lists.
Marking a package deprecated
In order to mark a package deprecated, a special virtual provides is added:
Provides: deprecated()
If the package has subpackages and the packager intends to deprecate the package as a whole, packager MUST mark all subpackages as being deprecated.
Name: mainpackage ... Provides: deprecated() ... %package subpackage ... Provides: deprecated()
Alternatively, a packager MAY decide to only deprecate some subpackages.
A packager SHOULD add a comment in the spec explaining why a package is being deprecated. For example:
# net-tools (ifconfig etc.) have been obsoleted for ~20 years upstream. # We want to get rid of it from Fedora in favor of the iproute package, # however many sysadmins still expect ifconfig to be there, so we keep it # around as a deprecated package. Provides: deprecated()
If a date for the final removal of the package from the distribution is known, it MAY be included as follows:
Provides: deprecated() == YYYYMMDD
The special deprecated() provide MUST NOT be added in any released branch of Fedora. It is acceptable to deprecate packages in rawhide (the master branch), the branch for an upcoming Fedora release (if one exists) up until the time of the Final Freeze, and to EPEL branches (at any time). Also note that because packages may exist in a deprecated state for some time, those packages can eventually enter release branches. The restriction is on the initial addition of the deprecated() tag.
Consequences of a package being deprecated
Technically, nothing changes; a deprecated package works and behaves as before. However, other packages in Fedora MUST NOT add a dependency on a deprecated package (that includes Requires, BuildRequires, Recommends, Suggests, etc.). This applies both for updates of existing packages and new packages added to Fedora. Those submitting new packages, along with package reviewers, MUST check to see if any dependencies of the package they are submitting or reviewing have been deprecated. (It is, however, acceptable for a deprecated package to be renamed.)