#36 Renaming BUILDTAGS and LDFLAGS to include GO prefixes
Opened 7 months ago by linkdupont. Modified 3 months ago

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.

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:

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:

1. Rebuild everything in a side-tag

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.

2. Support both old and new variables at the same time

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.

I agree. PR #41 proposes the patch for solution 1; do we have any objections to solution 1?

Login to comment on this ticket.

Metadata