fp-wiki>ImportUser (Imported from MoinMoin) |
m (PackagingDrafts/ProvidesObsoletes moved to Archive:PackagingDrafts/ProvidesObsoletes: appears to be in Packaging/NamingGuidelines with similar wording) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 28: | Line 28: | ||
For packages that are not usually pulled in by using the package name as the dependency such as library only packages (which are pulled in through library soname depenencies), there's usually no need to add the Provides. Note however that the -devel subpackages of lib packages are pulled in as build dependencies using the package name, so adding the Provides is often appropriate there. | For packages that are not usually pulled in by using the package name as the dependency such as library only packages (which are pulled in through library soname depenencies), there's usually no need to add the Provides. Note however that the -devel subpackages of lib packages are pulled in as build dependencies using the package name, so adding the Provides is often appropriate there. | ||
[[Category:Archived packaging guideline drafts]] | |||
Latest revision as of 20:25, 21 February 2009
Suggested clarification to packaging guidelines when to use Provides and Obsoletes, and when only Obsoletes:
Renaming/replacing existing packages
If a package is being renamed without any functional changes, or is a compatible enough replacement to an existing package (where "enough" means that it includes only changes of magnitude that are commonly found in version upgrade changes), provide clean upgrade paths and compatibility with:
Provides: oldpackagename = $provEVR Obsoletes: oldpackagename < $obsEVR
$provEVR refers to an (Epoch-)Version-Release tuple the original unchanged package would have had if it had been version or release bumped, using macros. $obsEVR is an (Epoch-)Version-Release tuple arranged so that there is a clean upgrade path, but without gratuitously polluting the version space upwards, usually not using macros.
If a package supersedes/replaces an existing package without being a compatible enough replacement as defined in above, use only the Obsoletes from above.
If the provided package had an Epoch set, it must be preserved in both the Provides and Obsoletes. It may and should be removed from the actual new package.
Example: foo being renamed to bar, bar is compatible with foo, and the last foo package release being foo-1.0-3%{?dist} with Epoch: 2; add to bar (and similarly for all subpackages as applicable):
Version: 1.0
Release: 4%{?dist}
Provides: foo = 2:%{version}-%{release}
Obsoletes: foo < 2:1.0-4
If there is no standard naming for a package or other long term naming compatibility requirements involved with the rename, the Provides should be assumed to be deprecated and short lived and removed in the distro release after the next one (ie. if introduced in FC-X, keep in all subsequent package revisions for distros FC-X and FC-(X+1), drop in FC-(X+2)), and the distro version where it is planned to be dropped documented in a comment in the specfile. Maintainers of affected packages should be notified and encouraged to switch to use the new name. Forward compatibility Provides: in older distro branches can be considered in order to make it possible for package maintainers to keep same simple specfiles between branches but still switch to the newer name.
For packages that are not usually pulled in by using the package name as the dependency such as library only packages (which are pulled in through library soname depenencies), there's usually no need to add the Provides. Note however that the -devel subpackages of lib packages are pulled in as build dependencies using the package name, so adding the Provides is often appropriate there.