(Created page with "= Dist Tag Guidelines = These are the guidelines for using the <code>%{dist}</code> tag in Fedora. Using the <code>%{dist}</code> tag is not mandatory, however, it is the only...") |
No edit summary |
||
(6 intermediate revisions by the same user not shown) | |||
Line 28: | Line 28: | ||
=== Possible values for %{dist} === | === Possible values for %{dist} === | ||
When you run <code> | When you run <code>fedpkg</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 | For Fedora, %dist takes on a value based on the Fedora release number, so Fedora N has a dist tag value of ".fcN". For example, on Fedora {{FedoraVersionNumber|current}} %dist would have the value ".fc{{FedoraVersionNumber|current}}". On the development branch of Fedora, <code>%{dist}</code> takes the version of the next unbranched version, so if Fedora {{FedoraVersionNumber|current}} is current, and {{FedoraVersionNumber|next}} has been branched, then in the development branch would get a dist tag value of ".fc{{FedoraVersionNumber|next2}}". | ||
For Red Hat Enterprise Linux, <code>%{dist}</code> again a value based on the RHEL major release number. In all RHEL6 versions, <code>%{dist}</code> has a value of ".el6". Note that RHEL dist tags are only defined for EPEL packages. | |||
Red Hat Linux | |||
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. | ||
=== %{dist} in the Release: field === | === %{dist} in the Release: field === | ||
When using <code>%{dist}</code> to mark a package as having been built for a specific distribution, you should include it in the Release field, like this: | When using <code>%{dist}</code> to mark a package as having been built for a specific distribution, you should include it in the Release field, like this: | ||
<pre> | <pre> | ||
Line 153: | Line 118: | ||
* <code>%{dist}</code> should never be used in the Name or Version fields, only Release, and only as documented above. | * <code>%{dist}</code> should 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> should never be used in the Name, Version, or Release fields. | * <code>%{fedora}</code>, <code>%{rhel}</code>, <code>%{rhl}</code>, <code>%{fc#}</code>, <code>%{el#}</code> should never be used in the Name, Version, or Release fields. | ||
Latest revision as of 21:20, 17 October 2016
Dist Tag Guidelines
These are the guidelines for using the %{dist}
tag in Fedora. Using the %{dist}
tag is not mandatory, however, it is the only permitted mechanism for marking the distribution revision of a package. This isn't because any other method is broken or bad, but because we need a consistent standard in Fedora.
You should consider this document as an addendum to the Packaging/NamingGuidelines .
Author: Tom 'spot' Callaway
Revision: 0.16
Initial Draft: Monday Mar 21, 2005
Last Revised: Monday, July 06 2009
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?
No. It is documented and standardized so that maintainers who wish to use it can do so, but it is not mandatory.
Using %{dist}
OK, so you've decided to use %{dist}
. Here is the important information to know:
Possible values for %{dist}
When you run fedpkg
, 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 Fedora, %dist takes on a value based on the Fedora release number, so Fedora N has a dist tag value of ".fcN". For example, on Fedora 41 %dist would have the value ".fc41". On the development branch of Fedora, %{dist}
takes the version of the next unbranched version, so if Fedora 41 is current, and 42 has been branched, then in the development branch would get a dist tag value of ".fc43".
For Red Hat Enterprise Linux, %{dist}
again a value based on the RHEL major release number. In all RHEL6 versions, %{dist}
has a value of ".el6". Note that RHEL dist tags are only defined for EPEL packages.
Note the leading period in the definition of %{dist}
. This is present so that it can easily be used in the release field.
%{dist} in the Release: field
When using %{dist}
to mark a package as having been built for a specific distribution, you should include it in the Release field, like this:
Release: 1%{?dist}
Basically, follow the ["Packaging/NamingGuidelines"] for how to set the value for Release, then append %{?dist}
to the end. 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 FC3 buildroot, it generates an rpm named: logjam-1.4-2.fc3.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 7 builds, %{fc7}
is defined to 1.
%{el#}
: This variable is only defined on Red Hat Enterprise Linux builds. For example, on RHEL 5 builds, %{el5}
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} >= 4 %endif %{?fedora:%global _with_xfce --with-xfce} %if 0%{?rhel} %if 0%{?rhl} %endif %endif %if 0%{?rhl}%{?fedora} %endif %{?fc8:Requires: foo} %{?fc7:Requires: bar} %{?fc6:Requires: baz} %{?fc5:Requires: quux}
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 cannot override the variables for
%{dist}
(or any of the related variables). - You cannot hardcode a value for
%{dist}
(or any of the related variables) in your spec. - You cannot hardcode a dist tag in the spec: BAD: Release: 1.fc6 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}
should never be used in the Name or Version fields, only Release, and only as documented above.%{fedora}
,%{rhel}
,%{rhl}
,%{fc#}
,%{el#}
should never be used in the Name, Version, or Release fields.