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
