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