Many tools written in golang bundle up their build dependencies along with their source code. For e.g. docker provides a 'vendor/' dir while kubernetes, etcd provide a 'Godeps/' dir and so on.

The current [https://fedoraproject.org/wiki/PackagingDrafts/Go golang packaging draft] mentions providing dependencies in the form of golang(github.com/project/repo/...) which are provided via golang sources packaged into rpms

I propose to prefer using bundled golang libs whenever available and depend on golang rpms if bundled libs aren't provided or aren't good enough. Following are some of the points that were brought up by a few other fellow golang packagers/maintainers (cc'd) and I.

FOR BUNDLED GOLANG LIBS

1. zero time spent in packaging up the deps

2. use versions/commits known to build the package successfully / tested by upstream

3. golang libs often end up having cyclic dependencies which are painful to solve via rpm updates.

4. golang libs sometimes move their source code hosting (for example: from googlecode to github causing changes in import paths and thus changes in package names, and metaproviding new import paths or creating new packages is an added overhead.)

FOR RPMS:
1. the bundled golang libs though available in tarballs released by the tools (docker/kube etc.) technically come from different upstreams.

1. sometimes the vendors bundling these tools may not have accounted for bug fixes patched in the upstream libraries, which might be easier to fix via rpms

cc'd folks please add anything I may have missed.