The Fedora packaging guidelines call for splitting all third-party code into separate packages based on the upstream. We need to do this in etcd. We're still working out how to do this in Go -- see https://fedoraproject.org/wiki/PackagingDrafts/Go, and the Docker spec file http://pkgs.fedoraproject.org/cgit/docker-io.git/tree/docker-io.spec for an example (although to be absolutely clear we don't actually have everything figured out yet). Anyway, all the stuff in third_party should be separate golang-* RPMs. Except maybe third_party/github.com/coreos/go-etcd -- I'm not sure what that's all about.
Third party deps are github.com/coreos/go-raft github.com/coreos/go-etcd github.com/ccding/go-logging github.com/ccding/go-config-reader bitbucket.org/kardianos/osext code.google.com/p/go.net code.google.com/p/goprotobuf We do have go.net packaged as golang-googlecode-net. go-raft is forked from https://github.com/goraft/raft, but described as "mainly a staging repo before being merged upstream". We should probably focus on the upstream. The other stuff we'll have to figure out. :)
I'm cool with taking any or all of these, unless there's any disagreement :)
I'm going ahead with all of them. If anyone wants to join in the fun, we can co-maintain :)
Lokesh, thanks! I just got pinged from release monitoring that etcd has a new version as of yesterday so I'll work on that.
Awesome -- thanks Lokesh. We'll make the review requests for the deps block this bug, which can serve as a tracker. The specfile for etcd itself will also need to change. Either patch the build script to not include the third_party/* loop, or else just remove everything in that directory before building. And we'll need to set GOPATH to not just PWD but that plus %{_datadir}/gocode. (See the docker-io.spec). It might just be easiest to duplicate the part of the build script in %build in the specfile, modified for our conventions. (Again, that's basically what we did in Docker.)
So, with the above, the %build section might look something like this. This version tries to follow the existing build script, modified in several places. We could also skip all of their variable-building and just do it directly -- that might be cleaner (and more like what we're doing in the docker-io.spec). But here's a start. %build ETCD_PACKAGE=github.com/coreos/etcd export GOPATH=${PWD}:%{gopath} SRC_DIR=${PWD}/src ETCD_DIR=$SRC_DIR/$ETCD_PACKAGE ETCD_BASE=$(dirname ${ETCD_DIR}) mkdir -p ${ETCD_BASE} ln -s ../../../ ${ETCD_DIR} ./scripts/release-version > release_version.go go build -v -a ${ETCD_PACKAGE} ---- and note that gopath would (currently -- eventually it might be in the golang package itself) be defined at the top of the spec file, like %global gopath %{_datadir}/gocode
Oh, wait -- that "release-version" script doesn't work -- it uses "git describe --tags HEAD", and the tarball isn't a git tree. So we'll need to do something else there.
(In reply to Luke Cypret from comment #4) > Lokesh, thanks! I just got pinged from release monitoring that etcd has a > new version as of yesterday so I'll work on that. Hello Luke! I already started bulding it, so no need to worry. I also added proper integradion with systemd (socket activation and all ncessary RPM stuff).
Thanks Peter, I'm reviewing your SRPM to see your changes. Once all of the other go packages get pushed to stable I'll fix etcd for the unbundled packages in a new release. Currently they are all in package review.
Ok, thanks to Lokesh we finally did it! Since etcd-0.1.2-5.fc21 it doesn't use any bundled libs but instead uses system-wide ones. I don't think we should hurry up and rebuild etcd for F19 and F20 since it doesn' add up any value to the end users, but we'll eventually rebuild etcd in these branches w/o bundled libs as well. I'm going to close this as "CLOSED/RAWHIDE".