make tag and %{?dist}

[Tom 'spot' Callaway]

On Wed, 2005-05-04 at 07:09 -0500, Josh Boyer wrote:
> On Wed, May 04, 2005 at 01:32:57PM +0200, Michael Schwendt wrote:
> > > 
> > > As for hardcoding being convenient, I disagree.  I think it's a pain.  I
> > > do not see why everyone should have to hardcode that when it could be
> > > done by the make targets.
> > 
> > Everything that is added to the tag on-the-fly is non-intuitive and bad.
> > I would not like it if cvs-import.sh altered my spec file, and I would not
> > like it if "make tag" used too much "magic" (like relying on CVS branch
> > directory file names instead of evaluating RPM macros).
> 
> I don't think what I'm proposing would change the spec file.  If you have a
> %{?dist} in your Release field, then it would evaluate to the correct value.
> If a spec file didn't use %{dist} at all, then nothing happens anyway...

The proposal I made (revision 240,764,842 or so) was the following:

If you wanted to have "automagic" dist values set, you could (if
implemented), pass a flag like "--usedist" to cvs-import.sh, or call
something like "make tag-dist" where it is explicitly performing the
magic, but not forcing it on those who don't give a red monkey's behind.

In the interim, what I've been doing (because I am the law), is
hardcoding dist tags into some of my packages to differentiate them.
There are two branches now (FC-3 and devel), and in the worst forseeable
case, we'll have four active branches, so thats a really minor one time
spec file change to make.

The primary reason I didn't want to hardcode the macros was to prevent
people from abusing the priviledge like so:

%define dist .FC3sucksandJoeWuzHereSoSuckIt

But, in retrospect, I realized that we would hopefully catch most of
these before they were built.

So, here's how you can use dist tags, right now:

If you want to use dist tags today, you have to hardcode the value in
your spec. There is no buildsystem checking to enforce that you're doing
it right, so I highly suggest that you checkin a spec for each branch
without a dist tag, do a full cvs checkout, then make the changes, and
cvs commit.

In the spec, as the first two lines, you should put:

%define dist .fc3
%define fedora 3

Where .fc3 is the appropriate value for the branch that the spec resides
in. Currently, the only permitted values are:

.fc3
.fc4

We're not building RHEL Extras (yet), so you shouldn't care about that
or the RHL values (.el4 or .rhl8). (However, Sopwith and I wrote a shell
script to do auto magic voodoo dist resolution, which should be in CVS
for redhat-rpm-config already). In the same line, "fedora" is the only
other var you should care about (rhl and rhel are the other correct
values, but again, not used in FE). 

Once this is done, you can change your Release from:

Release: 2

to

Release: 2%{?dist}

If you need to bump the release number, remember to change 2%{?dist} to
3%{?dist}.

The second variable (%fedora) is there so that you can perform numeric
conditionals like:

# Do something for FC4 and beyond.
%if "%fedora" >= "4"
    # ...
%endif

or distro conditionals like:

# One-liners, here set a default switch.
%{?fedora:%define _with_xfce --with-xfce}

Now, here is the mini-FAQ:

Q: Do I have to use dist tags?
A: No. You don't.

Q: Can I hardcode something other than .fc3 or .fc4 into %dist?
A: No.

Q: Does .fc3 have to be lowercase?
A: Yes. This is for consistency.

Q: Can't I just hardcode the .fc3 into the Release?
A: No.

Q: Can I put the actual release number after the %{?dist}?
A: No.

Q: I don't have any conditionals that use the %fedora macro, do I have
to define it?
A: Yes. Consistency (and it serves as a quick reminder that you've used
the right value).

Now, wrt to the automagic adding of dist, if there is enough interest in
that, you can either wait until I've got the time to add these things to
cvs-import.sh and the Makefile, or you can send me patches for review.

Hopefully, that clears up dist tag usage (although, its just as likely
to spawn another flame war).

~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!