m (Remove incorrect "not currently used" note.) |
(The dist tag is now mandatory. Clean up very ancient references to RHEL2, package CVS, and the like.) |
||
Line 2: | Line 2: | ||
--> | --> | ||
= Dist Tag Guidelines = | = Dist Tag Guidelines = | ||
Use of the <code>%{?dist}</code> is mandatory in Fedora. Please follow these guidelines for using the <code>%{?dist}</code> tag in Fedora. | |||
You should consider this document as an addendum to the [[Packaging/NamingGuidelines]] . | You should consider this document as an addendum to the [[Packaging/NamingGuidelines]] . | ||
{{Anchor|Purpose}} | {{Anchor|Purpose}} | ||
== Purpose of the Dist Tag == | == Purpose of the Dist Tag == | ||
There are several uses for a <code>%{dist}</code> tag. The original purpose was so that a single spec file could be used for multiple distribution releases. In doing this, there are cases in which BuildRequires: and Requires: will need to be different for different distribution releases. Hence, <code>%{dist}</code> does double duty: | There are several uses for a <code>%{?dist}</code> tag. The original purpose was so that a single spec file could be used for multiple distribution releases. In doing this, there are cases in which BuildRequires: and Requires: will need to be different for different distribution releases. Hence, <code>%{?dist}</code> does double duty: | ||
*it differentiates multiple packages which would otherwise have the same <code>%{name}-%{version}-%{release}</code>, but very different dependencies. | *it differentiates multiple packages which would otherwise have the same <code>%{name}-%{version}-%{release}</code>, but very different dependencies. | ||
Line 23: | Line 16: | ||
{{Anchor|IsItMandatory}} | {{Anchor|IsItMandatory}} | ||
=== Do I Have To Use the Dist Tag? === | === Do I Have To Use the Dist Tag? === | ||
Yes. It is very useful in maintaining proper ordering between Fedora releases and consistency in release tags is very helpful to the automated tools which are used to perform mass rebuilds. | |||
== Using %{dist} == | == Using %{dist} == | ||
Here is the important information to know: | |||
=== Possible values for %{dist} === | === Possible values for %{dist} === | ||
When you run <code> | When you run fedpkg commands like <code>fedpkg build</code>, the values for <code>%{dist}</code> and its helper variables are assigned according to the git branch that you are working in. You do NOT need to define these variables in your spec file. fedpkg will magically set <code>%{?dist}</code> for you. | ||
For reference purposes only, these are possible values for <code>%dist</code>: | |||
{| | |||
! OS !! %{?dist} tag | |||
|- | |||
| RHEL 5 (all variants) ||.el5 | |||
|- | |||
| RHEL 6 (all variants) || .el6 | |||
|- | |||
7 | | RHEL 7 (all variants) || .el7 | ||
|- | |||
| Fedora 19 || .fc19 | |||
|- | |||
| Fedora 20 || .fc20 | |||
|- | |||
| Fedora 21 || .fc21 | |||
|- | |||
|colspan="2"| (and so on) | |||
|} | |||
Development: | Development: | ||
Line 67: | Line 50: | ||
</pre> | </pre> | ||
Note the leading period in the definition of <code>%{dist}</code>. This is present so that it can easily be used in the release field. | Note the leading period in the definition of <code>%{?dist}</code>. This is present so that it can easily be used in the release field. | ||
These definitions can be found in common/branches. | These definitions can be found in common/branches. | ||
Note that RHEL dist tags are only defined for EPEL packages. | Note that RHEL dist tags are only defined for EPEL packages. | ||
=== %{dist} in the Release: field === | === %{?dist} in the Release: field === | ||
The <code>%{?dist}</code> tag is included in the Release field as follows: | |||
<pre> | <pre> | ||
Release: 1%{?dist} | Release: 1%{?dist} | ||
</pre> | </pre> | ||
This translates into: | |||
<pre> | <pre> | ||
If %{dist} is defined, insert its value here. If not, do nothing. | If %{dist} is defined, insert its value here. If not, do nothing. | ||
Line 89: | Line 72: | ||
Release: 2%{?dist} | Release: 2%{?dist} | ||
</pre> | </pre> | ||
When this package is built in an i386 | When this package is built in an i386 FC20 buildroot, it generates an rpm named: <code>logjam-1.4-2.fc20.i386.rpm</code>. | ||
Keep in mind that <code>%{dist}</code> should '''never''' be used in the Name or Version fields, nor in %changelog entries. | Keep in mind that <code>%{?dist}</code> should '''never''' be used in the Name or Version fields, nor in %changelog entries. | ||
=== Conditionals === | === Conditionals === | ||
Along with <code>%{dist}</code>, there are several "helper" variables defined by the buildsystem. These variables are: | Along with <code>%{?dist}</code>, there are several "helper" variables defined by the buildsystem. These variables are: | ||
<code>%{rhel}</code>: This variable is only defined on Red Hat Enterprise Linux builds. If defined, it is set to the release number of Red Hat Enterprise Linux present at build time. | <code>%{rhel}</code>: This variable is only defined on Red Hat Enterprise Linux builds. If defined, it is set to the release number of Red Hat Enterprise Linux present at build time. | ||
Line 103: | Line 86: | ||
<code>%{rhl}</code>: This variable is only defined on Red Hat Linux builds. If defined, it is set to the release number of Red Hat Linux present at build time. | <code>%{rhl}</code>: This variable is only defined on Red Hat Linux builds. If defined, it is set to the release number of Red Hat Linux present at build time. | ||
<code>%{fc#}</code>: This variable is only defined on Fedora builds. For example, on Fedora | <code>%{fc#}</code>: This variable is only defined on Fedora builds. For example, on Fedora 20 builds, <code>%{fc20}</code> is defined to 1. | ||
<code>%{el#}</code>: This variable is only defined on Red Hat Enterprise Linux builds. For example, on RHEL | <code>%{el#}</code>: This variable is only defined on Red Hat Enterprise Linux builds. For example, on RHEL 7 builds, <code>%{el7}</code> is defined to 1. | ||
All of these variables, if defined, will have a purely numeric value. | All of these variables, if defined, will have a purely numeric value. | ||
Line 116: | Line 99: | ||
%endif | %endif | ||
%if 0%{?fedora} >= | %if 0%{?fedora} >= 21 | ||
%endif | %endif | ||
Line 129: | Line 112: | ||
%endif | %endif | ||
%{? | %{?fc20:Requires: foo} | ||
%{? | %{?fc21:Requires: bar} | ||
%{? | %{?fc22:Requires: baz} | ||
</pre> | </pre> | ||
Line 148: | Line 128: | ||
Without the extra 0, if <code>%{rhel}</code> is undefined, the <code>%if</code> conditional will cease to exist, and the rpm will fail to build. | Without the extra 0, if <code>%{rhel}</code> is undefined, the <code>%if</code> conditional will cease to exist, and the rpm will fail to build. | ||
=== Things that you cannot use %{dist} for === | === Things that you cannot use %{?dist} for === | ||
* You | * You must not override the variables for <code>%{dist}</code> (or any of the related variables). | ||
* You | * You must not hardcode a value for <code>%{dist}</code> (or any of the related variables) in your spec. | ||
* You | * You must not hardcode a dist tag in the spec: '''BAD:''' Release: 1.fc20 '''GOOD:''' Release: 1%{?dist} | ||
* You cannot put any sort of "tagging" in <code>%{dist}</code> (or any of the related variables). <code>%{dist}</code> (and its related variables) exist ONLY to define the distribution that a package was built against. | * You cannot put any sort of "tagging" in <code>%{dist}</code> (or any of the related variables). <code>%{dist}</code> (and its related variables) exist ONLY to define the distribution that a package was built against. | ||
* <code>%{dist}</code> | * <code>%{?dist}</code> must never be used in the Name or Version fields, only Release, and only as documented above. | ||
* <code>%{fedora}</code>, <code>%{rhel}</code>, <code>%{rhl}</code>, <code>%{fc#}</code>, <code>%{el#}</code> | * <code>%{fedora}</code>, <code>%{rhel}</code>, <code>%{rhl}</code>, <code>%{fc#}</code>, <code>%{el#}</code> must never be used in the Name, Version, or Release fields. | ||
== Common questions == | == Common questions == | ||
Q: Why don't you just let the buildsystem (or packager) pass the value for dist to rpm, e.g. <code>rpm --with dist | Q: Why don't you just let the buildsystem (or packager) pass the value for dist to rpm, e.g. <code>rpm --with dist el7</code>? | ||
A: Actually, we do. The Fedora buildsystem defines the values for dist when you run <code> | A: Actually, we do. The Fedora buildsystem defines the values for dist when you run <code>fedpkg</code>. | ||
Q: | Q: Why is use of %{?dist} mandatory? | ||
A: | A: There are very few packages which didn't use it, the primary very old reason for not using it (sharing large data packages across Fedora releases) is no longer relevant because all Fedora releases are signed with a different key, and having consistent Release: tags simplifies the automated tools which may need to increment them. | ||
[[Category:Packaging guidelines]] | [[Category:Packaging guidelines]] |
Revision as of 20:27, 4 December 2014
Dist Tag Guidelines
Use of the %{?dist}
is mandatory in Fedora. Please follow these guidelines for using the %{?dist}
tag in Fedora.
You should consider this document as an addendum to the Packaging/NamingGuidelines .
Purpose of the Dist Tag
There are several uses for a %{?dist}
tag. The original purpose was so that a single spec file could be used for multiple distribution releases. In doing this, there are cases in which BuildRequires: and Requires: will need to be different for different distribution releases. Hence, %{?dist}
does double duty:
- it differentiates multiple packages which would otherwise have the same
%{name}-%{version}-%{release}
, but very different dependencies.
- it allows for a conditional check in the spec to deal with the differing dependencies.
Do I Have To Use the Dist Tag?
Yes. It is very useful in maintaining proper ordering between Fedora releases and consistency in release tags is very helpful to the automated tools which are used to perform mass rebuilds.
Using %{dist}
Here is the important information to know:
Possible values for %{dist}
When you run fedpkg commands like fedpkg build
, the values for %{dist}
and its helper variables are assigned according to the git branch that you are working in. You do NOT need to define these variables in your spec file. fedpkg will magically set %{?dist}
for you.
For reference purposes only, these are possible values for %dist
:
OS | %{?dist} tag |
---|---|
RHEL 5 (all variants) | .el5 |
RHEL 6 (all variants) | .el6 |
RHEL 7 (all variants) | .el7 |
Fedora 19 | .fc19 |
Fedora 20 | .fc20 |
Fedora 21 | .fc21 |
(and so on) |
Development:
The development branch takes the disttag of the next major unreleased version of Fedora.
Note the leading period in the definition of %{?dist}
. This is present so that it can easily be used in the release field.
These definitions can be found in common/branches.
Note that RHEL dist tags are only defined for EPEL packages.
%{?dist} in the Release: field
The %{?dist}
tag is included in the Release field as follows:
Release: 1%{?dist}
This translates into:
If %{dist} is defined, insert its value here. If not, do nothing.
So, if we have the following in a spec file:
Name: logjam Version: 1.4 Release: 2%{?dist}
When this package is built in an i386 FC20 buildroot, it generates an rpm named: logjam-1.4-2.fc20.i386.rpm
.
Keep in mind that %{?dist}
should never be used in the Name or Version fields, nor in %changelog entries.
Conditionals
Along with %{?dist}
, there are several "helper" variables defined by the buildsystem. These variables are:
%{rhel}
: This variable is only defined on Red Hat Enterprise Linux builds. If defined, it is set to the release number of Red Hat Enterprise Linux present at build time.
%{fedora}
: This variable is only defined on Fedora builds. If defined, it is set to the release number of Fedora present at build time.
%{rhl}
: This variable is only defined on Red Hat Linux builds. If defined, it is set to the release number of Red Hat Linux present at build time.
%{fc#}
: This variable is only defined on Fedora builds. For example, on Fedora 20 builds, %{fc20}
is defined to 1.
%{el#}
: This variable is only defined on Red Hat Enterprise Linux builds. For example, on RHEL 7 builds, %{el7}
is defined to 1.
All of these variables, if defined, will have a purely numeric value.
With %{dist}
and these additional variables, you can create conditionals in a spec file to handle the differences between distributions.
Here are some examples of how to use these variables in conditionals:
%if 0%{?rhel} %endif %if 0%{?fedora} >= 21 %endif %{?fedora:%global _with_xfce --with-xfce} %if 0%{?rhel} %if 0%{?rhl} %endif %endif %if 0%{?rhl}%{?fedora} %endif %{?fc20:Requires: foo} %{?fc21:Requires: bar} %{?fc22:Requires: baz}
Keep in mind that if you are checking for a specific family of distributions, that you need to use:
%if 0%{?rhel}
and NOT
%if %{?rhel}
Without the extra 0, if %{rhel}
is undefined, the %if
conditional will cease to exist, and the rpm will fail to build.
Things that you cannot use %{?dist} for
- You must not override the variables for
%{dist}
(or any of the related variables). - You must not hardcode a value for
%{dist}
(or any of the related variables) in your spec. - You must not hardcode a dist tag in the spec: BAD: Release: 1.fc20 GOOD: Release: 1%{?dist}
- You cannot put any sort of "tagging" in
%{dist}
(or any of the related variables).%{dist}
(and its related variables) exist ONLY to define the distribution that a package was built against. %{?dist}
must never be used in the Name or Version fields, only Release, and only as documented above.%{fedora}
,%{rhel}
,%{rhl}
,%{fc#}
,%{el#}
must never be used in the Name, Version, or Release fields.
Common questions
Q: Why don't you just let the buildsystem (or packager) pass the value for dist to rpm, e.g. rpm --with dist el7
?
A: Actually, we do. The Fedora buildsystem defines the values for dist when you run fedpkg
.
Q: Why is use of %{?dist} mandatory? A: There are very few packages which didn't use it, the primary very old reason for not using it (sharing large data packages across Fedora releases) is no longer relevant because all Fedora releases are signed with a different key, and having consistent Release: tags simplifies the automated tools which may need to increment them.