Overview
Request 812040 superseded
- Make all distributions get a proper Go metapackage version. This fixes issues
with 'BuildRequires: golang(API) >= 1.x' because in order for that fairly
widely used pattern to work, you need to have a Prefer'd package (which is
what the go metapackage is for). boo#1172608
- Created by cyphar
- In state superseded
- Superseded by 821110
Request History
cyphar created request
- Make all distributions get a proper Go metapackage version. This fixes issues
with 'BuildRequires: golang(API) >= 1.x' because in order for that fairly
widely used pattern to work, you need to have a Prefer'd package (which is
what the go metapackage is for). boo#1172608
jfkw accepted review
Thanks for this SR, I think we should accept this to devel:languages:go for a test period, and then submit to Factory:
Can you create a superseding SR with:
- %define go_api %{version} spelling in place of abi_version
- A comment that Version: must always be a valid golang(API) version e.g. go1.x
- Requires: go%{go_api} in place of %require_eq
(I think this might make L57 and L61 duplicates)
- Add BuildRequires: go%{go_api}-doc to match the others
- Enumerate the changes in the changelog entry subheadings:
* Use both BuildRequires: go%{go_api} and Requires: go%{go_api} to trigger build errors if go1.x is unavailable
* Add aarch64 to supported systems for go-race via %define tsan_arch x86_64 aarch64
* Add tsan_arch x86_64 aarch64 for suse_version >= 1500 and sle_version >= 150000, formerly conditional on suse_version >= 1315
* Ensure %ifarch %{tsan_arch} always evaluates (nil does not work) via dummy tsan_arch on systems where go-race is not supported
- Since packagers in other project may come with questions, expand the changelog entry with any detail you can add on the status quo and how this fixes problems currently seen.
Your sentence from https://bugzilla.suse.com/show_bug.cgi?id=1114209#c0 is helpful here:
Within OBS, if you have more than one option of a package to use for a build, the build will be considered unresolvable.
And some of the items in my #c17 attempt to summarize might also help explain:
openSUSE:Factory and other projects containing both the go metapackage and go1.x versions use project configuration "Prefer: go" to ensure a current version of go1.x is selected.
Thanks if you can incorporate those changes. My goal is for this to be submitted to Factory and SLE (and make its way to Leap) as one complete change once we know it works for people.
jfkw approved review
Thanks for this SR, I think we should accept this to devel:languages:go for a test period, and then submit to Factory:
Can you create a superseding SR with:
- %define go_api %{version} spelling in place of abi_version
- A comment that Version: must always be a valid golang(API) version e.g. go1.x
- Requires: go%{go_api} in place of %require_eq
(I think this might make L57 and L61 duplicates)
- Add BuildRequires: go%{go_api}-doc to match the others
- Enumerate the changes in the changelog entry subheadings:
* Use both BuildRequires: go%{go_api} and Requires: go%{go_api} to trigger build errors if go1.x is unavailable
* Add aarch64 to supported systems for go-race via %define tsan_arch x86_64 aarch64
* Add tsan_arch x86_64 aarch64 for suse_version >= 1500 and sle_version >= 150000, formerly conditional on suse_version >= 1315
* Ensure %ifarch %{tsan_arch} always evaluates (nil does not work) via dummy tsan_arch on systems where go-race is not supported
- Since packagers in other project may come with questions, expand the changelog entry with any detail you can add on the status quo and how this fixes problems currently seen.
Your sentence from https://bugzilla.suse.com/show_bug.cgi?id=1114209#c0 is helpful here:
Within OBS, if you have more than one option of a package to use for a build, the build will be considered unresolvable.
And some of the items in my #c17 attempt to summarize might also help explain:
openSUSE:Factory and other projects containing both the go metapackage and go1.x versions use project configuration "Prefer: go" to ensure a current version of go1.x is selected.
Thanks if you can incorporate those changes. My goal is for this to be submitted to Factory and SLE (and make its way to Leap) as one complete change once we know it works for people.
- Ensure 'Provides: golang(API) = %{api_version}' is consistent
to improve package resolution for common go dependency expressions
'BuildRequires: golang(API) >= 1.x' and BuildRequires: go >= 1.x
OBS projects that contain go code often have prjconf entries
'Prefer: go' which selects go metapackage over go1.x packages.
When go metapackage Provides: version is lower than go1.x versions,
'Prefer: go' is not effective and build failures occur with errors
unresolvable: have choice for golang(API) >= 1.13: go1.13 go1.14
Edits and changelog Jeff Kowalczyk
Refs boo#1172608
* Unify '{version'} and '{short_version}' as '{api_version}' for
'Provides: golang(API) = %{api_version}'
* Use both 'BuildRequires: go%{api_version}' and 'Requires: go%{api_version}'
to trigger build errors if go1.x is unavailable
* Add aarch64 to supported systems for go-race via
%define tsan_arch x86_64 aarch64
* Add tsan_arch x86_64 aarch64 for suse_version >= 1500 and
sle_version >= 150000, formerly conditional on suse_version >= 1315
* Ensure %ifarch %{tsan_arch} always evaluates (nil does not work)
via dummy tsan_arch on systems where go-race is not supported
We might want to spell it "api_version" instead of "abi_version" to make clear that go guarantees source compatibility but not not binary compatibility, and since binary packages were removed in go1.12.
While we're near the subject with this SR, I am considering introducing go(API) and deprecating golang(API), since the term golang is not encouraged by upstream. There will be potentially many Provides: go() expressions in the future (modules, etc.) , and we might as well fix the spelling now while the number of dependent packages are small. Any deprecation would remain in place for a suitable transition period.
I haven't seen this interesting macro used before (L39, L61):
%requires_eq go%{abi_version}
What does that expand to and how does it benefit? Is there a reason one Requires: is the non-macro form (L47)?
Requires: go%{abi_version}-doc
After finding some (not enough) information on macro %requires_eq, it appears to call out to rpm in the chroot build root environment to get the effective version used by the package. Do I have that right?
I see some comments in fedora about calling rpm from rpm being problematic, in part since the build environments rpm capability and db format can differ. Is there some other way we could calculate a sufficiently precise version to trigger the build error if not present? I haven't personally seen what that error looks like to the build log or end user, can you show an example?
https://github.com/rpm-software-management/rpm/issues/541
https://src.fedoraproject.org/rpms/redhat-rpm-config/c/924b9f3be4b4e8074af8d42b0f524092e8add189?branch=master
Given a BuildRequires, requires_eq generates a 'Requires' entry that has the same version. But if you prefer, I can just add both a Requires and BuildRequires on the Go version.
Could we drop the {abi_version} (propose spelling as api_version) define and use {version}, with a comment to only set major versions that are valid golang(API) versions e.g. go1.x? I can't think of a scenario where {api_version} would differ from {version} given the current packaging design.
On the other hand, keeping the indirection of:
%define go_api %{version}
in the go metapackage might provide helpful visual and grep alignment with the go.1x packages:
%define go_api 1.14
I think we should do this.
@andtecheu, @cyphar, @flavio_castelli, @jfkw, @jordimassaguerpla, @thipp: review reminder