In #34 and #35, it was brought up to rename the BUILDTAGS variable to GOBUILDTAGS in order to be more explicit about the intended use of the variables and to avoid any potential namespace collision with other variables. I looked into what packages are using BUILDTAGS today to figure out how much of an impact a rename like this will have.
BUILDTAGS
GOBUILDTAGS
As of this writing, the following packages are using BUILDTAGS in some capacity:
buildah.spec containernetworking-plugins.spec cri-tools.spec go-compilers.spec golang-github-prometheus-node-exporter.spec golang-github-prometheus.spec grafana.spec hugo.spec moby-engine.spec oci-seccomp-bpf-hook.spec pack.spec podman.spec reg.spec runc.spec skopeo.spec snapd.spec source-to-image.spec stargz-snapshotter.spec syncthing.spec weldr-client.spec
And the follow packages use LDFLAGS:
LDFLAGS
aerc.spec age.spec butane.spec clash.spec containerd.spec doctl.spec fzf.spec geoipupdate.spec git-lfs.spec golang-github-aliyun-cli.spec golang-github-colinmarc-hdfs-2.spec golang-github-haproxytech-dataplaneapi.spec golang-github-hub.spec golang-github-jsonnet-bundler.spec golang-github-magefile-mage.spec golang-github-prometheus.spec golang-github-rfjakob-gocryptfs.spec golang-github-tdewolff-minify.spec golang-github-theoapp-theo-agent.spec golang-mvdan-editorconfig.spec ignition.spec kiln.spec micro.spec open-policy-agent.spec osbuild-composer.spec rclone.spec reg.spec source-to-image.spec syncthing.spec tinygo.spec vgrep.spec weldr-client.spec
I identified these packages by grepping the contents of the current spec tarball.
To avoid breaking these packages that are currently using BUILDTAGS or LDFLAGS, there are two possible approaches I see to safely rename the variables:
Patch go-rpm-macros to rename BUILDTAGS and LDFLAGS to GOBUILDTAGS and GOLDFLAGS respectively. Then patch the above packages and stage them all in a side-tag to update them in one monolithic Bodhi update.
go-rpm-macros
GOLDFLAGS
Patch go-rpm-macros to support both BUILDTAGS/LDFLAGS and GOBUILDTAGS/GOLDFLAGS simultaneously. Then patch the above packages over time until everything has been ported over to using GOBUILDTAGS and GOLDFLAGS, and then drop the old variables from go-rpm-macros.
I'm not sure how easy either of these approaches will be. They are both moving targets as new packages are constantly getting added. It might just be a constant effort to try and keep on top of all the patches as new packages come along and patches need to be rebased onto their target's changes.
Ok, I am partisan of solution 1.
The state of the current macros regarding this provoked the mass failures with have seen due to the introduction of relro which is not recognized by the Golang compiler.
What is the scope of this change? Do we apply it only on Rawhide? Do we apply it to stable branches? What about EPEL9?
Applying it on stable branches is dangerous, but people tends to git merge from Rawhide to stable branches and it would cause head scratching issues. Same problem for Fedora to EPEL9 merges. I'not sure how to apply solution 2 either.
RHEL/C9S has probably some packages that depends on the BUILDTAGS and LDFLAGS variables and we can't modify them easily. I also don't know if the relro flag will also be set on RHEL.
Pinging kindly @dbenoit regarding RHEL/C9S.
We really need to do this now that %set_build_flags is going to get executed automatically in package build environments in %build, %install, and %check phases.
%set_build_flags
%build
%install
%check
I agree. PR #41 proposes the patch for solution 1; do we have any objections to solution 1?
I've rebased the PR. Not sure which packages will need fixing after that.
This is covered by https://pagure.io/go-rpm-macros/c/bc7e5cc55c4709e8ea56f832d04c3235a25ebf00?branch=master. At some point, we can completely remove the fallback to the non-GO_ prefixed variables and stop disabling %set_build_flags.
GO_
Log in to comment on this ticket.