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