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(a)wieers.com,
http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]