Bug 1999335

Summary:	BUILDTAGS vs. GOBUILDTAGS
Product:	Red Hat Enterprise Linux 9	Reporter:	Brian Lane <bcl>
Component:	go-rpm-macros	Assignee:	David Benoit <dbenoit>
Status:	CLOSED WONTFIX	QA Contact:	qe-baseos-tools-bugs
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	9.0	CC:	asm, carl, dbenoit, emachado, ngompa13, obudai, tstellar
Target Milestone:	rc	Keywords:	FutureFeature, Triaged
Target Release:	---	Flags:	pm-rhel: mirror+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-03-02 07:27:47 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 Brian Lane 2021-08-30 22:59:30 UTC

Description of problem:
Fedora doesn't have BUILDTAGS in their version of go-rpm-macros. This makes builds that assume the macros are consistent between distros build with unexpected results.

I've tried to submit a patch for Fedora, but Neal Gompa is insisting on GOBUILDTAGS. I assume that's going to cause issues since people are already using BUILDTAGS as the name.

Could the maintainers of go-rpm-macros please coordinate with each other so that users have a consistent experience between distros?

Comment 1 Brian Lane 2021-08-30 23:00:17 UTC

Forgot the Fedora PR - https://pagure.io/go-rpm-macros/pull-request/34

Comment 2 Neal Gompa 2021-08-30 23:35:10 UTC

For what it's worth, before today, I had no idea that RHEL forked and rewrote almost all the Go macros downstream. This was quite a shock to me. I hadn't heard from anyone working on RHEL's Go compiler stack about this, nor had anyone reached out to me or anyone else in the Fedora Go SIG about this issue before today (after everything happened). So I am extremely confused and slightly upset about the current situation.

Comment 6 RHEL Program Management 2023-03-02 07:27:47 UTC

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.