Improve compliance with major packaging guidelines

[jmccormick2001]

Packaging guidelines for go software has been heavily discussed on the Debian and Go mailing lists, resulting in a preliminary spec for Debian:\r\n\r\nhttp://thread.gmane.org/gmane.linux.debian.devel.general/179252\r\nhttp://grokbase.com/t/gg/golang-nuts/13124dm049/go-nuts-rfc-debian-packaging-of-go-libraries-and-programs\r\nhttp://pkg-go.alioth.debian.org/packaging.html\r\n\r\nAnd RedHat has worked on their own draft packaging guidelines, explicitly trying to match Debian when sensible:\r\n\r\nhttps://fedoraproject.org/wiki/PackagingDrafts/Go\r\n\r\nCPM should follow this guidelines to the extent it's possible to do so, as they are not fully mature themselves yet.\r\n\r\nOn a first pass over these documents, the first thing I noticed is that Fedora is using the word \"vendoring\" for Go programs that bundle other packages. Since their model expects that they will build all dependencies instead as RPMs, their sample .spec file wipes out those files:\r\n\r\n rm -rf vendor\r\n\r\nIf it's feasible to split CPM's bundled software into a vendor/ subdirectory like that, rather than simply sharing the src/ directory with the CPM code, that would make future RPM packaging simpler. Making the Crunchy code logically separate from the bundled pieces would be nice regardless.

[jmccormick2001]

this is an interesting area for sure, and difficult to solve completely given a lot of factors....Myself and\r\nAdam talked about this last week actually where it resulted in this issue being created for\r\nthe dnsbridge project:\r\n\r\nhttps://github.com/CrunchyData/dnsbridge/issues/1\r\n\r\nsome background, I chose the 'vendoring' model when I started due to that model being\r\nused by the openshift and kube teams, and my own reading of the various options 8 months ago.\r\n\r\nSadly, I think the godep idea is STILL not fully baked at the moment and find it incredibly \"unsatisfying\" as a dep mgmt approach, but a lot of golang projects use godep alongside their 'vendoring' models.\r\n\r\nUltimately, the vendoring model has worked for me because I've not had to deal with a lot of \r\ndependencies yet, this will likely change with the next round of Openshift v3 porting which I'm about to embark upon. That will pull in a LOT of dependencies due to the way they package openshift/kube. My hope is that the Openshift team addresses this and creates the proper \"client\" libs for CPM to use instead of requiring us to pull in the whole backend. I should know more how this goes shortly but I think this one will be tough. Or perhaps Redhat will come up with something as this issue suggests. Interestingly Google likes it the way it is and doesn't seem interested in making too many changes, so I suspect other vendors (e.g. Redhat) will attempt to create an alternative.

[jmccormick2001]

From Adam: Yeah, from what I can tell, 'vendoring' is the name of the game for the most part. I toyed with godep a bit which is heavily built around the idea of 'vendoring'. I'm not sure that I really liked the approach, but is what it is. The one thing I did like about it, however, was that it was trying to put some order to the chaos that I believe 'vendoring' can become. Cataloging versions to each lib I felt was one of the benefits (and a must have especially if you are going to follow the RedHat method for packaging), however, I still think it needs a little more time in the oven.\r\n\r\nI do, however, like the idea of having 'our' source separate from '3rd party' source. Therefore, as Greg mentions, if it were possible to extract the '3rd party' sources from the 'src/' directory, then I think that would be a step in the right direction.

[jmccormick2001]

From Greg: I have no problem with shipping these vendor bits. That is what everyone else is doing. I just want the way we're shipping those to be as compatible as possible with how Debian and RedHat are working around the problem.\r\n\r\nIf we separate out the imported bits into their own subdirectory, which RedHat is expecting will be named vendor/ in the tree, that's probably good enough. Then if RHEL wants to package their own CPM, their build process will automatically blow all that source code away, so instead they can compile their own separate go-uuid etc.

[jmccormick2001]

at this point, I'm not sure I see a real action to take here, I'll continue to look at how various golang apps are packaged and the various standards as they emerge, but currently golang frameworks/libs are just not packaged in a consistent way like C libs are.