Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 2100579

Summary: Please add `%{?distsuffix}` to `%dist` definition in /usr/lib/rpm/macros.d/macros.dist
Product: Red Hat Enterprise Linux 9 Reporter: Maxwell G <maxwell>
Component: redhat-releaseAssignee: Stephen Gallagher <sgallagh>
Status: CLOSED ERRATA QA Contact: Release Test Team <release-test-team-automation>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: CentOS StreamCC: bstinson, jwboyer, kevin, lisas, pzatko, sgallagh
Target Milestone: rcKeywords: Triaged
Target Release: ---Flags: pm-rhel: mirror+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: redhat-release-9.1-1.8.el9 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-11-15 10:49:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Maxwell G 2022-06-23 18:36:52 UTC 
Description of problem:
Now that %dist has other macros in its definition[1] besides just including ".elX", there is no easy way to add a suffix to the dist tag (e.g. .next for epel-next or .ap for Ansible Automation Platform) without loosing the other information.

[1]: https://gitlab.com/redhat/centos-stream/rpms/centos-release/-/blob/c9s/centos-stream-release.spec#L139

This is causing issues in EPEL 9 Next, but Red Hat products could also be affected. Currently, we override %dist to '.el9.next' in the epel9-next buildroot. We can't just override `%dist` to `%{!?distprefix0:%{?distprefix}}%{expand:%{lua:for i=0,9999 do print("%{?distprefix" .. i .."}") end}}.el9.next%{?with_bootstrap:%{__bootstrap}}` due to limitations in Koji.

You can take golang-x-sys as an example. This package uses the forge macros (part of redhat-rpm-config in c9s/RHEL 9) that put git commit information into `%distprefix`. We want the NVR to be `golang-x-sys-0-24.20220604gitbc2c85a.el9.next', but it is currently `golang-x-sys-0-24.el9.next` when built in Koji.

This also breaks other packages/macros that utilize `%distprefix` and/or the `%bcond_without bootstrap` logic. It has the potential to cause NVR collisions and update sorting issues.

We suggest adding `%{?distsuffix}` to the %dist definition in /usr/lib/rpm/macros.d/macros.dist. This would allow us (and anyone else who builds against EL 9) to simply define %distsuffix and leave the definition of %dist alone. I have proposed https://gitlab.com/redhat/centos-stream/rpms/centos-release/-/merge_requests/30 which does just that.

Version-Release number of selected component (if applicable):
centos-stream-release-9.0-12.el9.noarch
(I was instructed to open this issue against redhat-release, as there's no centos-release component)

Additional info:
See https://pagure.io/releng/issue/10852 for more information and discussion about this issue.
Comment 1 Brian Stinson 2022-06-23 19:08:59 UTC 
I don't necessarily see any trouble with adding this, but is the koji restriction the one that @kfenzi mentioned in the EPEL ticket? 

You're allowed to set macros in rpm.macros.dist on the koji tags, in fact we make heavy use of this in the CentOS Stream and RHEL buildsystems:
https://kojihub.stream.rdu2.redhat.com/koji/taginfo?tagID=5

If we update this in centos/redhat-release we'll need to update our buildsystems as well.
Comment 2 Maxwell G 2022-06-23 20:47:46 UTC 
> https://kojihub.stream.rdu2.redhat.com/koji/taginfo?tagID=5
I believe https://kojihub.stream.centos.org/koji/taginfo?tagID=5 is the publicly accessible version.
Comment 3 Kevin Fenzi 2022-06-23 20:56:07 UTC 
So, I was going from the koji docs: 

```
This feature is best used for macros with simple values that need to be managed by tag administrators.
The canonical example is managing the ``%dist`` macro, but other simple macros would also make sense.

We do not recommend setting complicated macros in this way.
E.g. macros that contain complex expansions, or those that are central to the rpmbuild process.
```

But I suppose we can just do that if it's worked ok for you... or could ask the koji developers how likely this is to break... 

FYI, I tend to not use my work email/bugzilla account for bugzilla if possible. :)
Comment 4 Maxwell G 2022-06-23 21:33:22 UTC 
Even if it is possible to set this in Koji, I think adding `%{?distsuffix}` is a better, simpler, less error prone solution. And, if the `%dist` definition ever changes in centos/redhat-release, we wouldn't have to worry about syncing it to multiple places.

> If we update this in centos/redhat-release we'll need to update our buildsystems as well.

Well, it still should work for the time being, as long as package maintainers don't use this new, undocumented macro in their packages in an already released RHEL version...
Comment 14 errata-xmlrpc 2022-11-15 10:49:19 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (redhat-release bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:8264