I had an insightful discussion with Sopwith this afternoon, and we
discussed the idea of dist tags, and some important discussion arose:
Elliot pointed out that for any given .src.rpm, the name-version-release
needs to stay fixed for all builds of that .src.rpm. Otherwise it
becomes impossible to track packages back to their source, keep an audit
trail, etc.
The problem with using the macros is that if a maintainer does 'make
build' on an fc3 box, then they get the dist tag value from that machine
in the n-v-r. When they go to check this into CVS (say, into the fc4
branch), its wrong. We don't want someone doing 'make tag' on the FC-4
branch and having n-v-r = foo-1.2-3.fc3.
But at the same time, we also want to avoid forcing the packagers to
have to put the dist value into the spec manually. This defeats the
entire reason for dist tags, which is to have a single spec that can be
used for multiple distributions.
We discussed a lot of options, but Elliot came up with a good idea,
which is best explained by giving an example of a new package commit:
- I'm a maintainer, of package logjam.
- I make a single spec for all possible fc builds using the documented
"approved" dist macros
- I set Release: 1 (note, no %{dist})
- I make my src.rpm.
- I then run ./cvs-import.sh --use-dist --branch=fc4
logjam-1.0.0-1.src.rpm
- The cvs-import script does the following:
- Checks my spec to make sure that n-v-r doesn't have %{dist} in it
already
- Notes the value of the branch that I'm checking this package into
- Uses that value and adds the following lines to the top of my spec
%define fedora 4
%define dist .fc4
- Appends %{?dist} to the end of Release (so it becomes
Release: 1%{?dist} )
- Commits the spec with the added defines into the branch.
Now, with this mechanism, if I want to do multiple branches for a single
spec, its easy, cvs-import.sh does the work for me. We keep a single
n-v-r per branch, and there is no naming conflicts between branches.
The branch-copy operations would just change the values of the macros,
or add the macros near the top if they're not already in the .spec file.
We'd want to add a check in the buildsystem to make sure that people
haven't polluted the %{dist} defines, but that shouldn't be terribly
difficult.
Now, for people wanting to take their original spec and build it
somewhere else, say for RHEL, we could use a set of rpm macros. Elliot
and I worked on a simple shell script that parses /etc/redhat-release
and returns (depending on the flag chosen):
The version of RHEL for %{_el} (if on RHEL)
The version of Fedora for %{_fedora} (if on Fedora)
The version of RHL for %{_rhel} (if on RHL)
The number of the distro for %{_distnum}
The type of the distro for %{_disttype}
The dist tag value for %{_dist}
The macros then become as simple as:
%_dist %{expand:%%(/usr/lib/rpm/redhat/dist.sh --dist)}
%_distnum %{expand:%%(/usr/lib/rpm/redhat/dist.sh --distnum)}
%_disttype %{expand:%%(/usr/lib/rpm/redhat/dist.sh --disttype)}
%_rhel %{expand:%%(/usr/lib/rpm/redhat/dist.sh --el)}
%_fedora %{expand:%%(/usr/lib/rpm/redhat/dist.sh --fc)}
%_rhl %{expand:%%(/usr/lib/rpm/redhat/dist.sh --rhl)}
The script is already checked into CVS for redhat-rpm-config. If you
wanted to build off that spec for RHEL, you'd just need to add these 7
lines to your local .rpmmacros file.
This provides a standardized, easy way to do single-spec, multiple
distribution packaging. But of course, there are bound to be
complications.
Please ponder this implementation, and offer feedback.
Thanks,
~spot
--
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!
