Policies/Release Tag
From Mandriva
Contents |
Preamble
Some packages which use %mkrel may have warnings that send you here (although the warnings are no longer necessary now that %mkrel use has been standardised and all necessary macros are now handled by the rpm-mandriva-setup package).
If:
- you are a maintainer
- you are rebuilding a package which implements this proposal
- you were sent here by a message it gave you during the build
- you are building the package on an official cooker build host, and the packages will be uploaded to cooker main or cooker contrib then you may want to ensure that all packages implementing this proposal build correctly on the build machines, which you can do by adding this to your ~/.rpmmacros:
%_with_unstable --with-unstable
This will ensure that each package will be built as if you had run rpm '--with unstable' ..., and save you some typing.
However, note that this has already been done on most official cooker build hosts (when rpm-4.2.3-5mdk was uploaded), so you may rather want to check with the build host maintainer.
If you are:
- not a maintainer
- rebuilding packages from cooker for a stable release
- building on a non-cooker host
then please make no changes. All you would do is introduce more pain for the users who run your packages, where the whole point of this proposal it to make it easy to avoid this pain. You will guarantee the ire of the maintainer of the cooker package by doing this, and probably increase the effort he/she has to spend supporting the package.
Recommendation for packagers
When to use %mkrel
Starting with Mandriva 2007.0, the new release tag policy includes the target version in the release tag for all the packages, including the cooker one. As a consequence maintainers are encouraged to use %mkrel all the time.
Up to Mandriva 2006.0, %mkrel was primarily of use when a user recompiled a package from cooker on a stable version.
How to use it
The %mkrel macro as defined below was added to the rpm-4.2.3-5mdk package. Thus, to implement %mkrel for packages in pre-10.2 cooker and later, all you would need to do is change:
%define release 1mdk Release: %release
to
%define release %mkrel 2 Release: %release
Backport hosts for 10.1 and older should define the macro in the local macros file.
In the case where you want SRPMS implementing %mkrel to build successfully by others on hosts you have no control over, you should conditionally define the macro in the spec file, as follows:
%{?!mkrel:%define mkrel(c:) %{-c:0.%{-c''}.}%{!?''with''unstable:%(perl -e '$''="%{1}";m/(.\'''\\D\+)?(\\d+)$/;$rel=${2}-1;re;print "$1$rel";').\
%{?subrel:%subrel}%{!?subrel:1}.%{?distversion:%distversion}%{?!distversion:%(echo $[%{mdkversion}/10])}}\
%{?''with_unstable:%{1}}%{?distsuffix:%distsuffix}%{?!distsuffix:mdk}}
Note that in this case, it seems rpm will only expand macros used in a %define statement, so you cannot do:
%define release 1 Release: %mkrel %release
Instead, use:
%define rel 1 %define release %mkrel %rel Release: %release
You may still want to notify the user, however this is no longer necessary:
%{?!''with''unstable: %{error:%(echo -e "\n\n\nYou are building an unofficial package, please see \n\
http://qa.mandrakesoft.com/twiki/bin/view/Main/DistroSpecificReleaseTag\nif you think this is incorrect\n\n\n
The proposals below should be considered deprecated in favour of these recommendations, but are retained for reference purposes.
Why
Why do we need a distribution-specific release tag? Well, let's see ...
Users want new packages
One of the biggest complaints about Mandriva Linux from relatively advanced users (i.e. users who want new software but aren't yet comfortable building their own packages) is that it takes too long (even with a 6 month release cycle) to get the latest software.
A good example of this problem is Mozilla Firefox 1.0 which was released about 1 week after Mandrakelinux 10.1 Official.
Why not user cooker?
But, we know that cooker is almost always (basically except when in freeze) up-to-date with the latest bleeding-edge packages.
But, for a user who wants 4 or 10 new packages, should they really need the bandwidth to run cooker? Should they really deal with the breakage that is inevitable?
StefanVanDerEijk: Bandwidth shouldn't be an issue for these "advanced" users.
BuchanMilne: The experience of a user is orthogonal to the bandwidth they have.
StefanVanDerEijk: Preventing breakage and maintaining a supported system will become more challenging.
BuchanMilne: This is the problem of the backports project, which will need to define policies on allowable changes.
Current solution and it's problems
The current solution is to suggest that a user rebuilds the package from cooker, or find someone who has done it. Many packages (including samba, cyrus-imapd, postfix(?), mozilla-firefox) currently explicitly make provision for being built on older releases, to make this easier.
This would be an adequate solution (and indeed the Projects/BackPorts project wants to automate this in the future), except that this could place the user in a dangerous situation.
StefanVanDerEijk: This is the choice of the user. He is responsible for the packages that he installs, we can never be made responsible for that, unless only Mandrivakesoft signed packages can be installed.
RPM believes that all packages with the same Epoch, Version and Release are identical (well, RPM may believe that the ARCH makes a difference, but urpmi doesn't, and how should RPM sort ARCHes?). However, rebuilding a SRPM from one distribution will not result in an identical package. At best, the package is noarch, and does not have release specific scripts or contents. A worse situation is where a library a binary package depends on has changed major number, in which case, after an upgrade, the Requires will not be satisfied, leaving the user to either ignore the dependencies and break their system, or go without a package. The worst case is where a binary package depends on a library that differs between the two distributions, but there is no difference in the Requires that were detected at build time, guaranteeing the user of breakage.
StefanVanDerEijk: The exact order that RPM uses to determin upgradeability are: Epoch - Version - Release?
StefanVanDerEijk: We may be looking for an epoch like tag (epoch tags aren't visible in the rpm package name either) that appends this: Epoch - Version - Release - Disttag.
Packages that differ must explicitly differ via Epoch/Version/Release
Since RPM assumes that any two packages with the same Epoch/Version/Release are identical, the only solution to making the life easier for those who rebuild from cooker is to ensure that packages rebuilt from cooker are seen as older than the package in cooker.
Since it is likely that different users will rebuild the same packages from cooker on different distributions and publish them (this already happens), and it is even possible that users would want to upgrade between two stable releases and additional rebuilds from cooker, the only sane solution is to include the distribution version in the EVR.
Now, you may think "but, the packages from different machine running the same release won't be identical". You may be right, but there are criteria we could use to determine if they are "identical enough". And, unless we upgrade the default versions of libraries on a stable release, builds on different hosts running the same release should be binary-compatible.
How should packages be named?
The hard requirement is that the %release tag for one "release" of a package, when backported, should always be smaller than the original %release tag, but greater than the previous %release tag (whether backported or not). So, if 3.0-1mdk is in stable release 10.0, 3.0-2mdk is in cooker, rebuilding 3.0-2mdk should result in a package with a release tag 1mdk < %release < 2mdk.
Existing naming conventions
Mandriva Linux security updates
The security update packages already embed the distribution version in the %release tag, using $[%{release}-1].%foo.$[%{mdkversion}/10]mdk.
StefanVanDerEijk: in a non-standardized, ad-hoc fashion.
BuchanMilne: Implementing it for all backported packages makes in non-ad-hoc, and defines a standard. Lack of a standard is what is creating the ad-hoc fashion (see the disparity of release tags in current 3rd-party packages).
Streamlining cooker and updates may be possible if we use the same naming policy and (as in the case of samba) even allow security updates to be direct cooker rebuilds.
Red Hat / Fedora
Red Hat Enterprise Linux 3 uses a release tag that looks like this: %release.3E
Fedora Core 1/2/3 seems to use release tags such as: %release.FC(1|2|3)
Proposal %{NAME}-%{?EPOCH:%EPOCH-}%{VERSION}-$[%{RELEASE}-1].%{SUBRELEASE}].$[%{mdkversion}/10]
Implementation
To implement this, the spec file of packages claiming support for backporting should contain macros similar to:
%define rel 1
%define subrel 1
%define release %{rel}%{distsuffix}
%{?!''with''unstable: %define release %(echo $[%rel-1].%{subrel}.%{distversion}
The official macros for the distribution should include something similar to:
%distsuffix mdk
%distversion %(echo $[%{mdkversion}/10])
Official build hosts should also be configured with the additional macro:
%_with_unstable --with-unstable
(a better named macro may be more appropriate, maybe %_with_develdistro)
Until such time as the macros are implemented in the distribution, spec files should not assume their presence, but rather use something like this:
%define rel 1
%define subrel 1
%define release %{rel}mdk
%{?!''with''unstable: %define release %(echo $[%rel-1].%{subrel}.$[%{%mdkversion}]
Of course, if distributions that should be supported are known to not provide a required macro, the macros should be provided conditionally:
%{?!mdkversion: %define mdkversion %(perl -pe '/(\d+)\.(\d)\.?(\d)?/; $_="$1$2".($3||0)' /etc/mandrake-release)}
Until official build hosts are configured for a suitable macro defining them as an official build host, it may also be worthwhile to either cater for other packagers rebuilding your package on a well-known host, or warning the user that they are building an unofficial package. This can either be implemented as:
%define release %(caseostname in (n?.mandrakesoft.com) echo %rel;;(*) echo $[%rel-1].%subrel.$[%mdkversion/10];;esac)mdk
or
%{?!''with''official: %{error: You are building an unofficial package, please see http://qa.mandrakesoft.com/twiki/bin/view/Main/DistroSpecificReleaseTag}}
Additionally, at present the architecture maintainers seem to have enough work on their plate for one distribution, and they would prefer it if release tag maths were to be limited to the commodity distribution, so any release tag maths should be wrapped with %ifarch i586.
Other things to consider may be to warn the user if they are building on a distribution the packager does not support:
%if %mdkversion < 9200
%{error: You are building on a release of the distribution not supported by the packager, bug reports will be ignored}
%endif
Cut-and-paste macros
If you want to apply this proposal on your packages, assuming you previously had entries like this in your spec file:
%define release 1mdk [...] Release: %release
You should change that to read
%define rel 1
%define subrel 1
%{?!distversion:%define distversion %(echo $[%{mdkversion}/10])}
%{?!distsuffix:%define distsuffix mdk}
%define release %{rel}%{distsuffix}
%ifarch i586
%{?!''with''unstable: %define release %(echo $[%rel-1].%{subrel}.%{distversion}%{distsuffix})}
%{?!''with''unstable: %{error:%(echo -e "\n\n\nYou are building an unofficial package, please see \n\
http://qa.mandrakesoft.com/twiki/bin/view/Main/DistroSpecificReleaseTag\nif you think this is incorrect\n\n\n ")}%(sleep 4)}
%endif
mklibname-like implementation
Using the cut-and-paste macros incurs a package maintenance overhead, it may be better to make a macro similar to the Mandriva Linux %mklibname macro, which can have a standard definition of the arguments, but be tailored to a specific distribution. This would allow more flexible package naming.
Here is a sample implementation:
%mkrel(c:) %{-c:0.%{-c''}.}%{!?''with''unstable:%(perl -e '$''="%{1}";m/(.\''')(\\d+)$/;$rel=${2}-1;re;print "$1$rel";').\
%{?subrel:%subrel}%{!?subrel:1}.%{?distversion:%distversion}%{?!distversion:%(echo $[%{mdkversion}/10])}}\
%{?''with_unstable:%{1}}%{?distsuffix:%distsuffix}%{?!distsuffix:mdk}
Some examples:
$ rpm --eval '%mkrel 5' 4.1.101mdk $ rpm --with unstable --eval '%mkrel 5' 5mdk $ rpm --eval "%mkrel -c ate +%Y%m%d 5" 0.20041214.4.1.101mdk $ rpm --with unstable --eval "%mkrel -c ate +%Y%m%d 5" 0.20041214.5mdk
The macro allows for customised %distsuffix and %distversion macros, so if we wanted to build the same package on RHEL3 (for example), we could use something like this:
$ rpm --define 'distsuffix E' --define 'distversion 3' --eval '%mkrel 5' 4.1.3E
Using the %mkrel macro
If you wanted to use the %mkrel macro, you would do something like this:
# define the mkrel macro if it is not already defined
%{?!mkrel:%define mkrel(c:) %{-c:0.%{-c''}.}%{!?''with''unstable:%(perl -e '$''="%{1}";m/(.\''')(\\d+)$/;$rel=${2}-1;re;print "$1$rel";').\
%{?subrel:%subrel}%{!?subrel:1}.%{?distversion:%distversion}%{?!distversion:%(echo $[%{mdkversion}/10])}}%{?''with_unstable:\
%{1}}%{?distsuffix:%distsuffix}%{?!distsuffix:mdk}}
%define rel 6
Release: %mkrel %rel
(Note, you might want to use RPM Pre- Or CVS-Version)
Pro's
- Intends to ensure a smooth upgradepath to the latest current distro, while not adding new tags to the official packages.
- It can be implemented on a package-by-package basis, without any inconsistency in the official packages.
Con's
- Users will be confused by the release number in the changelog differing from the release number of the package
We should ensure that users who read the changelog should be aware of the policy.
- Packages that have dependencies based on package versions will break
BuchanMilne: How? Please give a concrete example. AFAIK, only packages built from the same SRPM should have inter-dependant = = dependencies (which are implicitly satisfied), everything else should use > or <, which is catered for by this proposal.
- The %SOURCERPM tag in the binary package is generated from the macro and is not the real src.rpm that has been used to build the package
- Users can circumvent the scripts, making packages that resemble "official" Mandriva packages
An official Mandriva package is one that is signed by Mandriva. If a user installs a package it built onto the system, this is his responsibility. Possible solutions:
- Detect non-Official packages with the Mandriva tooling
- Make an option in the Mandriva tooling to re-install (rpm -Uvh --replacepkgs --replacefiles) these unofficial packages
BuchanMilne: Remember, this proposal is not about preventing users from shooting themselves in the foot, it's about not giving them a loaded gun. If they want to go out of their way to make their own lives difficult, that's their problem. If they go out of their way to make the lives of others difficult ... well ... the community can deal with it until it really becomes a problem.
Proposal (EPOCH)-NAME-VERSION-$[RELEASE]mdk%%{mdkversion}
This system is being used by Axel Thim of atrpms.net, who maintains a large repository of packages which are rebuilt for several release of Fedora / RedHat. Axel bumped into the issue of building packages for multiple distribution releases, and came up with the following:
The .rpmmacros file contains the following:
%atrelease() %1.%{disttag}.at
%distinitials mdk
%disttag %{distinitials}%{distversion}
%distversion %(rpm -qf --qf='%{VERSION}' /etc/mandrake-release)
The spec file then contains:
Release: %atrelease 55
Where "55" is the release of the package. This then results in a version tag like: 55.mdk10.2.at
Pro's
- It becomes clear for all packages on which distro they have been built.
- It doesn't intend to provide a false sense of end-user protection.
BuchanMilne Is this a necessary goal? At present, people plainly rebuilding packages from cooker already have this false sense of end-user protection, and "Users can circumvent the scripts, making packages that resemble "official" Mandriva packages"
Con's
- Longer releasetag for all packages.
- To be consitant, all packages in a distro will need to be built with this policy.
- To maintain this consistency, every time the mandriva-release changes %{VERSION}, all packages need to be rebuilt. This is probably a good thing in the end, but it means that auto-rebuilding the entire distribution needs to be automated and work - thus delaying implementation of this policy until such time as this actually works.
- The %SOURCERPM tag in the binary package is generated from the macro and is not the real src.rpm that has been used to build the package.
- It requires defining macros in the .rpmmacros file, thus if we aim to prevent users shooting themselves in the foot, either the /etc/rpm/macros file provided by RPM needs to be populated with suitable macros, or this scheme is not suitable.
Proposal (EPOCH)-NAME-VERSION-RELEASE-(DISTTAG)
Perhaps a hidden, optional tag can be added, that can ensure the smooth upgrade process.
