#496 golang packaging: prefer using bundled golang libs as dependencies if available
Closed: Duplicate None Opened 9 years ago by lsm5.

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

zero time spent in packaging up the deps

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

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

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:

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

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.


I think it might be useful to put in some guideline about tracking the bundled dependency chain in some sort of metadata, and/or requiring bundled golang packages to provide a /usr/share/doc/${package}/Godeps.json (similar to [https://github.com/openshift/origin/blob/master/Godeps/Godeps.json OpenShift Origin V3]). I don't necessarily think that we should try to enforce this specific Godeps toolchain (i.e. - try to force it upon upstream projects) but should be the responsibility of a packager to provide at least similar data such that the state of a package installed on a system that was built with bundled libraries could be inspected/audited.

Replying to [comment:1 maxamillion]:

I think it might be useful to put in some guideline about tracking the bundled dependency chain in some sort of metadata, and/or requiring bundled golang packages to provide a /usr/share/doc/${package}/Godeps.json (similar to [https://github.com/openshift/origin/blob/master/Godeps/Godeps.json OpenShift Origin V3]). I don't necessarily think that we should try to enforce this specific Godeps toolchain (i.e. - try to force it upon upstream projects) but should be the responsibility of a packager to provide at least similar data such that the state of a package installed on a system that was built with bundled libraries could be inspected/audited.

That's doable I guess. docker provides a vendor.sh with exact commit values of deps used while kubernetes, etcd, flannel and rocket provide Godeps.json.

And of course, if upstreams don't provide bundled deps, we could then depend on rpms.

The golang guidelines aren't complete at this point, so I would suggest working with the existing draft in https://fedorahosted.org/fpc/ticket/382. Hopefully someone can move that whole thing forward. I don't really think there need to be two parallel tickets on this, and trac doesn't appear to allow me to merge them, so I'm just going to close this.

Login to comment on this ticket.

Metadata