linkdupont reported a new issue against the project: `go-rpm-macros` that you are following: `` 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](https://src.fedoraproject.org/repo/rpm-specs-latest.tar.xz).
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. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/36
eclipseo added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/36
ngompa added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/36
linkdupont added a new comment to an issue you are following: `` I agree. PR #41 proposes the patch for solution 1; do we have any objections to solution 1? ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/36
eclipseo added a new comment to an issue you are following: `` I've rebased the PR. Not sure which packages will need fixing after that. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/36
gotmax23 added a new comment to an issue you are following: `` This is covered by https://pagure.io/go-rpm-macros/c/bc7e5cc55c4709e8ea56f832d04c3235a25ebf00?b.... At some point, we can completely remove the fallback to the non-`GO_` prefixed variables and stop disabling `%set_build_flags`. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/36
golang@lists.fedoraproject.org
-
Link Dupont -
Maxwell G
-
Neal Gompa
-
Robert-André Mauchin