[Fedora-packaging] dist tag revisited

[Michael Schwendt]

On Sun, 03 Apr 2005 20:39:07 -0500, Tom 'spot' Callaway wrote:

> 
> > Please ponder this implementation, and offer feedback.
> 
> Since no one has offered any feedback, either no one cares, or what I've
> proposed is acceptable without comment.
> 
> Please let me know which one is accurate. :)

IMO, the former. I've lost interest in dist tags which require more
than appending %{?dist} (or a hardcoded tag) to the release field.

We keep packages in a CVS layout with multiple branch directories, not in
a single CVS directory with real CVS-style branches. If we wanted to share
a single spec for multiple target distributions, we ought to have a
build-system which can pull a src.rpm from a CVS-style branch, a single
tag _or_ a specific directory and append a dist tag on-the-fly (e.g. by
defining %dist). Then we would really share a single source for multiple
platforms.

The process you describe looks too manual and too error-prone to me. It
involves automated modification of a spec file during CVS import, adding
hardcoded distribution specific constants and leading to CVS contents
which differ in multiple branches. To support this process, the package
developer needs to keep a pristine src.rpm somewhere else (for pre-commit
building and testing of a single src.rpm on multiple platforms) or import
a modified fc4 src.rpm into the fc3/fc2 branches and let the script
replace the inserted constants. Package development should look different
for 98% of the package developers: update working copy, build test
packages on all target platforms, test on all target platforms, cvs
commit. With constants hardcoded in the spec--just to work around cvs
tagging problems--this is changed.

All it takes to add a dist tag, when there is minimal benefit, is to
hardcode it in the spec file in the proper branch directory prior to
commit. Tools like diff and patch make it convenient enough to duplicate
package updates into multiple branch directories.

The other rpm macros are helpful, though.