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