From Fedora Project Wiki
(no name, optional date)
(Mark this page as a draft so it doesn't appear in the regular guidelines category.)
 
Line 44: Line 44:
 
Technically, nothing is changed, 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. Package Reviewer MUST check if required packages are not deprecated. There are possible exceptions for this rule, for example when the review is done as a rename of another existing package.
 
Technically, nothing is changed, 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. Package Reviewer MUST check if required packages are not deprecated. There are possible exceptions for this rule, for example when the review is done as a rename of another existing package.
  
[[Category:Packaging guidelines]]
+
[[Category:Packaging guidelines drafts]]

Latest revision as of 00:48, 15 June 2018

Sometimes a package is intended to be removed from Fedora, however it is kept in Fedora for some more (often undefined) time, mostly for backwards compatibility. In order to prevent new packages to depend on such package, packagers can mark it as deprecated.

Marking a package deprecated

Warning.png
Deprecate only in development/EPEL branches!
Do not deprecate packages in other branches than Branched (until the Final Freeze), Rawhide (master) and EPEL branches.

A package maintainer may decide to make their package deprecated only if nothing in Fedora requires it. Alternatively a packager may decide to deprecate a set of packages that are only required from within the set. Deprecating packages that are still required requires a FESCo approved Fedora change. A packager SHOULD communicate package deprecation to other packages, preferably trough the Fedora devel mailing list.

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 deprecated as well.

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 lot of sysadmins still expect ifconfig to be there, so we keep it
# around as a deprecated package.
Provides:  deprecated()

If a date for the deprecation is known, it MAY be included as follows:

Provides:  deprecated() == YYYYMMDD

Consequences of a package being deprecated

Technically, nothing is changed, 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. Package Reviewer MUST check if required packages are not deprecated. There are possible exceptions for this rule, for example when the review is done as a rename of another existing package.