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/16d4081420ba606c5f476ab334deb6ff15cdc930)

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.