[Fedora-packaging] disttag

[Dag Wieers]

On Tue, 1 Mar 2005, Michael Schwendt wrote:

> On Tue, 01 Mar 2005 07:41:08 -0600, Tom 'spot' Callaway wrote:
> 
> > Let me reiterate. I am fundamentally opposed to a disttag that can
> > "expand to virtually everything". Hence, the macro definition of
> > disttag, and the limitation of the defined possiblities.
> 
> Let me expand on my comment then.
> 
> We don't use the disttag for branding, do we? The purpose of appending a
> disttag to the package release is not in flagging a package file as being
> for a specific distribution environment. If you disagree, a tag like
> "2.el4" is a very poor choice.
> 
> The purpose of a disttag postfix -- is it the primary or sole purpose? --
> is in making it possible that a single src.rpm can be built for multiple
> distribution releases without needing to worry about EVR comparison for
> upgrade paths.
> 
> Using this disttag postfix is transparent to the packager, except for the
> %{?disttag} macro that must be appended to the Release value. Whether the
> postfix will be ".FC2", ".fc3", ".RHEL4" or empty should not be something
> the package developer needs to worry about. Yes, the macro can be
> undefined and then would expand to nothing and would append nothing. This
> would be the case for every build machine which isn't updated to define
> %disttag somewhere.
> 
> Hence I'd like to avoid a multi-purpose macro, which is not only used to
> append a release postfix, but which is also relied on upon finding out the
> build target distribution.
> 
> The earlier posted dist tag list 
> 
>   0.el2 0.rh7 0.rh8 0.rh9 1.el3 1.fc1 1.fc2 1.fc3 2.el4 2.fc4 2.fc5
>   2.fc6 3.el5
> 
> is enough of a kludge already. An ugly kludge, which pretends an upgrade
> path which is unsupported, and which makes package file names ugly too.
> But it would achieve what it's supposed to achieve, provided that every
> package update is built and released for all newer distro releases.
> 
> But please, if we go as far as defining a %disttag value somewhere in our
> build environments, which is also to be used for determining the target
> distro in conditional spec sections, better let's define a second macro. A
> second macro, which has the sole purpose of making it unnecessary to
> examine redhat-release in the spec file.
> 
> That one could be everything from a generic %distribution value to a
> specific %{?fedora} and %{?rhel}, which expand to a numerical release
> version. Would also allow much more obvious rpmbuild --define "fedora 4"
> builds.  I'd rather check for "%{?rhel}" == "4" than to check for
> "%{?disttag}" == ".2.el4".

RPMforge uses %{dist} for providing the release, like:

	el2, el3, el4, rh6, rh7, rh8, rh9, fc1, fc2, fc3

We don't have a disttag, because this is appended to the Release-tag by 
the buildsystem (since the only real reason is to have it in the 
Release-tag and only in the Release-tag, it does not actually have to be 
inside the SPEC file anyway). The prefix dot also is no longer required.

This allows us to do things like:

	%{?dist: %{expand: %%define %dist 1}}
and
	%{?el2:%define _without_alsa 1}
and
	%if %{?el2:1}%{?el3:1}%{?el4:1}0

Some of these things look ugly, I agree. But since I'm not a developer and 
a change in RPM is less desired anyway, it's probably the closest we can 
go if the functionality is required.

I would like to expand the RPM language somehow to allow for constructs 
like:

	%if %{dist} in ('el2', 'el3', 'el4')
or
	%if %{dist} matches '^el'

If new things are added to RPM, we either require a backport to older 
rpm-build or wait wcs 7 years (el4 eol) to start using the functionality. 
Something FE does not have to worry about as much as I do though.

So is there a reason why we have to have the disttag and cannot have the 
buildsystem rewrite the SPEC file ?

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]