Am 23.05.2014 11:22, schrieb Sauyon Lee:
As noted on https://wiki.archlinux.org/index.php/Go_Package_Guidelines#Naming, most go packages would end up becoming VCS packages, and having suffixes for no reason is a bit of a pain.
They *are* VCS packges. Naming doesn't change anything about it. With the suffix you know they are. However, I didn't know that exception for go. And there are actual go packages in AUR that do build from tarball. Not sure how you guys want to see the difference or if you guys care.
My main reasoning for not forcing a specific hash is that it would do nothing but make packaging more difficult, as the likelihood of an official package for a golang binary is rather slim simply because of the utility of the 'go get' command.
Well, yes: if there isn't even a tag in the repository you would choose an arbitrary hash/commit, which doesn't make much sense. When a tag is available, I wouldn't care that much though if that tagged version is built using git or a tarball (although I still prefer tarballs..). Anyways, I am not actively using go so these are just my 2 ct. I did read [1] though, if anybody else is interested on how go package management is supposed to work in a stable way without having any tags or releases. I wouldn't use system-wide packages at all since the go concept doesn't seem to go well with it. [1]: http://golang.org/doc/faq#get_version