Bug 1919348

Summary: go-compilers-golang-compiler and go-srpm-macros provide different %gobuild macros
Product: Red Hat Enterprise Linux 8 Reporter: Edjunior Barbosa Machado <emachado>
Component: go-srpm-macrosAssignee: David Benoit <dbenoit>
Status: NEW --- QA Contact: Edjunior Barbosa Machado <emachado>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.4CC: cfergeau, dbenoit, obudai, opohorel
Target Milestone: rcKeywords: FutureFeature, Reopened, Triaged
Target Release: 8.0   
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-07-23 07:31:14 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 Edjunior Barbosa Machado 2021-01-22 16:01:11 UTC
Description of problem:
Both go-compilers-golang-compiler-1-20.el8 from CRB repo and go-srpm-macros-2-17.el8 from AppStream provide different versions of %gobuild macro.

In a system with both installed, %gobuild macro from go-compilers-golang-compiler takes precedence over the definition from go-srpm-macros.

Version-Release number of selected component (if applicable):
go-srpm-macros-2-17.el8
go-compilers-golang-compiler-1-20.el8

Steps to Reproduce:

When only go-srpm-macros installed, %gobuild is defined as:

[root@ci-vm-10-0-138-246 ~]# rpm -qa go-srpm-macros go-compilers-golang-compiler
go-srpm-macros-2-17.el8.noarch
[root@ci-vm-10-0-138-246 ~]# rpm -E '%gobuild'

CGO_CPPFLAGS="-D_FORTIFY_SOURCE=2 -fstack-protector-all" go build -compiler gc -buildmode pie '-tags=rpm_crashtraceback libtrust_openssl ' -ldflags "-linkmode=external -compressdwarf=false ${LDFLAGS:-} -B 0x$(head -c20 /dev/urandom|od -An -tx1|tr -d ' \n') -extldflags '%__global_ldflags'" -a -v -x ;
[root@ci-vm-10-0-138-246 ~]# 

Compared to another system with both go-compilers-golang-compiler and go-srpm-macros installed:

[root@ci-vm-10-0-139-131 ~]# rpm -qa go-srpm-macros go-compilers-golang-compiler
go-srpm-macros-2-17.el8.noarch
go-compilers-golang-compiler-1-20.el8.x86_64
[root@ci-vm-10-0-139-131 ~]# rpm -E '%gobuild'

%ifnarch ppc64 
go build -buildmode pie -compiler gc -tags=rpm_crashtraceback -ldflags "-compressdwarf=false ${LDFLAGS:-} -B 0x$(head -c20 /dev/urandom|od -An -tx1|tr -d ' \n') -extldflags '%__global_ldflags'" -a -v -x ;
%else 
go build -compiler gc -tags=rpm_crashtraceback -ldflags "-compressdwarf=false ${LDFLAGS:-} -B 0x$(head -c20 /dev/urandom|od -An -tx1|tr -d ' \n') -extldflags '%__global_ldflags'" -a -v -x ;
%endif
[root@ci-vm-10-0-139-131 ~]#

Comment 12 RHEL Program Management 2022-07-22 07:28:05 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.

Comment 13 Ondřej Pohořelský 2022-07-22 13:36:04 UTC
Reopening this bug, because both packages still exist in RHEL 8 and both provide different %gobuild macro.
Adding FutureFeature keyword, so this doesn't get automatically closed again.

Comment 18 RHEL Program Management 2023-01-22 07:27:37 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.

Comment 23 RHEL Program Management 2023-07-23 07:31:14 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.