search

gofed / go-macros

Rpm mechanics for Go packaging
4 stars 7 forks source link

golist --provided should identify bundled code and generate the corresponding provides #7

Open nim-nim opened 6 years ago

nim-nim commented 6 years ago

golist --provided should identify vendored/bundled code and generate the corresponding bundled() provides

ingvagabund commented 6 years ago

INFO: the is applicable only to rpms that ship go binaries. It does not make sense to provide the bundled provides in devel only rpms. All the bundled provides should be collected in time the %gobuild macro is invoked (all imported packages must be reacheable from GOPATH/vendor). Each invocation generating a specific file. E.g.

%gobuild [opts] github.com/coreos/etcd/cmd/etcdctl

producing github.com.coreos.etcd.cmd.etcdctl.bundled file that gets read in the auto-generated provides.

nim-nim commented 6 years ago

No this is applicable to any shipped file whether it is built or not If you ship vendored code in a devel package, with a legal problem, it needs to be identified with bundled()

(and actually you should change the package license to match all the licenses of the vendored code you install which is why shipping vendored code in devel packages is a terrible idea from a legal POW)

ingvagabund commented 6 years ago

I am against shipping anything under vendor, Godeps, etc. Of course, we can not stop packages from doing that unless it violates the Fedora packaging guidelines. We can use the vendored deps to run tests, to build binaries. However, it does not make sense to use them as dependencies of a devel subpackage.

nim-nim commented 6 years ago

Anyway, this part is working again now in the shell code, no need to change golist for it (there will be a need to mark one way or another builds done with vendored code however)