Bug 481023 - Define macros.dist for RPM like Fedora does
Summary: Define macros.dist for RPM like Fedora does
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: redhat-release
Version: 5.3
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Daniel Mach
QA Contact: Release Test Team
: 564188 594986 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2009-01-21 19:24 UTC by Greg Swift
Modified: 2010-05-25 14:38 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-04-24 10:55:30 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Greg Swift 2009-01-21 19:24:02 UTC
Description of problem:
Building RPMs that utilize the %{dist} and %{rhel} macros require the macros to be explicitly defined by builder in some manner.  It would be very handy if Fedora's practice of including the /etc/rpm/macros.dist file was provided in RHEL.

Version-Release number of selected component (if applicable):
all RHEL that you would be willing to do it on.

How reproducible:

Steps to Reproduce:
1. rpm --eval '%{rhel} %{dist}'

Actual results:
%{rhel} %{dist}

Expected results:
5 .el5 (or 3, or 4)

Additional info:

Comment 1 Daniel Mach 2009-04-24 10:55:30 UTC
I see benefit in having the %dist macro set in /etc/rpm/macros.dist,
but don't forget that our customers can build their own packages with custom %dist.
In that case, adding default %dist could override their settings and possibly break build environment or their package naming policy.

I'm rather not going to do this change unless there is a really good reason to do so.
You can always build custom rpm defining these macros and add it to your build environment.

Comment 2 Greg Swift 2009-05-04 17:39:15 UTC
I can think of 4 primary methods that a builder would define their custom macros:

1: inside an /etc/rpm/macros.* file
2: via their .rpmmacros file
3: via --define at rpmbuild cli
4: inside the spec file

Because of how the variable are overridden as you go down the list I see only two ways that this addition would override a builder's current custom settings.

1: If they are using the macros.dist file and the RPM overwrites or replaces it, which is a packaging gotcha that could be dealt with.
2: They are using macros.[0-9a-z]* as their file, thus .dist would be loaded after, which is where I believe your concern stems from.

(I realize I may not be taking custom build environments or koji into account in the above)

One of the primary reasons I thought to bring this up was the building of Fedora or EPEL SRPMs on a RHEL box.  A good handful of packages that I've worked with do some logic based on these macros, and I have seen a few threads on the rpm list questioning how and where this information is defined, so it has some current viable good to it.

While I still see a strong benefit to adding this to existing RHEL releases, if it won't be, so be it.  That being said, I still think that it should be looked into for future releases.  When these builders go to set this up on their new systems they have to set it up initially anyways, so what would be the harm of pushing a standard and fairly upstream (fedora) place for them to do so?

Comment 3 Daniel Mach 2010-02-12 08:29:42 UTC
*** Bug 564188 has been marked as a duplicate of this bug. ***

Comment 4 Daniel Mach 2010-05-24 07:28:30 UTC
*** Bug 594986 has been marked as a duplicate of this bug. ***

Comment 5 Alexander Todorov 2010-05-25 14:01:50 UTC
in the duplicate bugs you said:

we already decided not to add macros to redhat-release in RHEL5.
I recommend you to keep using buildsys-macros.

What's the reason for this decision? Can you be more verbose? 

Wrt comment #1 above I don't see the difference with RHEL6 where those macros are included. In RHEL6 as well customers can build their own packages and the stock macros can override their custom %dist breaking build environments. If this is not going to be an issue in RHEL6 why is it in RHEL5?

Note You need to log in before you can comment on or make changes to this bug.