I don't think it is a good idea to debundle golang dependencies for epel7 as there is a high chance of migrating epel7 projects into rhel7 causing repeated removal of dependencies from epel7.

The same happened for etcd. I am not against debundling in epel7. However, after experience with fedora and el6, it just another overhead without much benefits. What project in epel7 needs goauth2?

This makes a lot of sense, but is the first I've heard of this policy. I put the same comment on the gofed bug.

The Fedora Go packaging draft needs an update with this information.

Right, Go packaging draft has still some unfinished issues and holes. Lets put it into a list of issues [1].

[1] https://github.com/gofed/gofed/issues/77

https://fedoraproject.org/wiki/PackagingDrafts/Go#Packaging_Binaries, subsection "Bundled or de-bundled".

This update actually does not change anything. It is just a note. [1] says:

"EPEL packages should only enhance and never disturb the Enterprise Linux distributions they were build for."

and

"The packages in the repository should, if possible, be maintained in similar ways to the Enterprise Packages they were built against"

Justification:
- goauth2 depends on 3 other projects: 
BuildRequires: golang(golang.org/x/net/context)
BuildRequires: golang(google.golang.org/appengine)
BuildRequires: golang(google.golang.org/appengine/urlfetch)
BuildRequires: golang(google.golang.org/cloud/compute/metadata)
- net depends on:
BuildRequires:  golang(code.google.com/p/go.text/encoding)
BuildRequires:  golang(code.google.com/p/go.text/encoding/charmap)
BuildRequires:  golang(code.google.com/p/go.text/encoding/japanese)
BuildRequires:  golang(code.google.com/p/go.text/encoding/korean)
BuildRequires:  golang(code.google.com/p/go.text/encoding/simplifiedchinese)
BuildRequires:  golang(code.google.com/p/go.text/encoding/traditionalchinese)
BuildRequires:  golang(code.google.com/p/go.text/encoding/unicode)
BuildRequires:  golang(code.google.com/p/go.text/transform)
- appengine on:
BuildRequires: golang(github.com/golang/protobuf/proto)
BuildRequires: golang(golang.org/x/net/context)
- cloud on:
BuildRequires: golang(github.com/golang/protobuf/proto)
BuildRequires: golang(golang.org/x/net/context)
BuildRequires: golang(google.golang.org/api/bigquery/v2)
BuildRequires: golang(google.golang.org/api/container/v1beta1)
BuildRequires: golang(google.golang.org/api/googleapi)
BuildRequires: golang(google.golang.org/api/storage/v1)
BuildRequires: golang(google.golang.org/grpc)
BuildRequires: golang(google.golang.org/grpc/credentials)
BuildRequires: golang(google.golang.org/grpc/credentials/oauth)
- grpc on:
BuildRequires: golang(github.com/bradfitz/http2)
BuildRequires: golang(github.com/bradfitz/http2/hpack)
BuildRequires: golang(github.com/golang/glog)
BuildRequires: golang(github.com/golang/protobuf/proto)
BuildRequires: golang(golang.org/x/net/context)
BuildRequires: golang(golang.org/x/net/trace)
BuildRequires: golang(golang.org/x/oauth2)
BuildRequires: golang(golang.org/x/oauth2/google)
BuildRequires: golang(golang.org/x/oauth2/jwt)
- and I can continue with http2,glog

https://github.com/golang/oauth2 project does not provide any Godeps.json file or mechanism to state which commits of each dependency is required. So at best I can guess and approximate. This is a general problem of golang projects.

What it would mean to package goauth2 for epel7:
1) repeat packaging hell as we already have in Fedora
2) invest packaging and maintenance time (and doable to work already done in Fedora)
3) create unstable environment as goauth2 dependencies can change over time
4) risk possible removal of goauth2 and all its dependencies due to their transfer to RHEL7.

This is quite disturbing and orthogonal to the current effort committed in RHEL7.

[1] https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy
[2] https://fedorahosted.org/fesco/ticket/1483#comment:17

===========================

Packaging goauth2 for epel7 is not against policy. However, I don't recommended it. It generates more work with almost no benefits. In future, all the work can be in vain. Feel free to request for new epel7 branch for goauth2 and git merge from master branch. I would reconsider and ask Fesco for exception for epel7 branch. Or if there is an argument that can be found complying with policies [1] and [2]. Maybe "goauth2 project does not provide a reliable way of building from system libraries due to unstability of its changing dependencies breaking backward compatibility". In this cause it would comply with the third sentence in [1].

golang-googlecode-goauth2-0-0.15.git8914e50.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-3ba8ead003

golang-googlecode-goauth2-0-0.15.git8914e50.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-3ba8ead003

golang-googlecode-goauth2-0-0.15.git8914e50.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.