linkdupont reported a new issue against the project: `go-rpm-macros` that you are
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:
And the follow packages use `LDFLAGS`:
I identified these packages by grepping the contents of the [current spec
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