Bug 481023

Summary: Define macros.dist for RPM like Fedora does
Product: Red Hat Enterprise Linux 5 Reporter: Greg Swift <gregswift>
Component: redhat-releaseAssignee: Daniel Mach <dmach>
Status: CLOSED WONTFIX QA Contact: Release Test Team <release-test-team-automation>
Severity: low Docs Contact:
Priority: low    
Version: 5.3CC: atodorov, opensource
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-24 10:55:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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:
Always

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
Daniel,
in the duplicate bugs you said:

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

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?