[go-rpm-macros] Issue #36: Renaming BUILDTAGS and LDFLAGS to include GO prefixes

[Link Dupont]

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

[Robert-André Mauchin]

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

[Neal Gompa]

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

[Link Dupont]

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

[Robert-André Mauchin]

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