Hi, I took me some time to do some tests and try to understand the issues. I am going to make a small summary here. We have 2 options: 1- add back the*"Requires: **golang(API) = **X.Y.Z" *2- Do not build the .a files, but just***provide the source code** * My proposal:* *Requires: golang(API) = X.Y.Z, and provide the source code in a subpackage called "-devel"* _Long explanation_ * *Context *In devel:languages:go, we are packaging golang-* packages so that they contain binary *.a files . If we want to use this *.a files, we need to add the packages as "BuildRequires". This happens for example for docker. Docker -- "Build Requires" --> md2man md2man -- "Build Requires" --> blackfriday md2man and blackfriday are both golang-* packages. The problem is that all of them need to be built with the same go version. Otherwise, when packaging go, you get this error: /error:object is [linux amd64 go1.6.2 X:none] expected [linux amd64 go1.6.1 X:none]"/ *Options* Thus we have basically 2 options: 1- add back the*"Requires: **golang(API) = **X.Y.Z",* as Marguerite already suggested (see her commit in her namespace https://github.com/marguerite/golang-packaging/commit/16d4081420ba606c5f476a...) Here there was some confusion. This package is a "*build**dependency*", see docker as an example, thus, in this scenario, you should see the "Requires" as "BuildRequires". I don't think we are expecting anyone installing it unless they want to build a go program. 2- Do not build the .a files, but just *provide the source code*, so that the final package builds everything. This is what Darix and Aleksa suggested, and it is what Fedora guys are doing. See the example of how to package a library at the end of its wiki page: https://fedoraproject.org/wiki/PackagingDrafts/Go Note, they are providing the files in a subpackage called "-devel". * Comparison of options* The advantage of this second approach is that you can have different go versions but only one golang-A package, while with the first approach, you should have as much golang-A packages as go versions, for example: First approach: go1-5 go1-6 golang-A-1.5 golang-A-1.6 Second approach: go1.5 go1.6 golang-A However, the first approach would have sense if we were using *shared libraries*. Marguerite has stated that she is working on that direction. * My proposal* Since Marguerite has already done the job as for providing the binaries, and she is doing so because she has plans for shipping it as shared libraries, I would not drop all her job and _add back the__*"Requires: *__*golang(API) = **X.Y.Z". *_However, I would also add a *_subpackage called "-devel" which provides the source files_* so that we can use that as Fedora guys do, cause in my opinion, that is a better approach.