[aur-general] Removing godep-git
Hello, I recently uploaded a sadly very broken PKGBUILD to the AUR and named it godep-git. However, after reading the packaging guidelines, I've decided that it really should be just "godep," as the project has no releases, so I'm going to be uploading a working PKGBUILD under that name in a (hopefully) short amount of time. Therefore, could you please remove godep-git? Thanks, Sauyon
Am 23.05.2014 06:46, schrieb Sauyon Lee:
I recently uploaded a sadly very broken PKGBUILD to the AUR and named it godep-git.
However, after reading the packaging guidelines, I've decided that it really should be just "godep," as the project has no releases, so I'm going to be uploading a working PKGBUILD under that name in a (hopefully) short amount of time.
Your package seems to have been deleted already, but I disagree: If your PKGBUILD always builds the current git version (using git) then it should be named godep-git. If they start making releases another package "godep" can be created (without using git). https://aur.archlinux.org/packages/go/godep/PKGBUILD *is* a git package. You should at least force a specific git hash or tag to make it a stable package. -- JonnyJD
On Fri, May 23, 2014 at 2:13 AM, Johannes Dewender <arch@jonnyjd.net> wrote:
Am 23.05.2014 06:46, schrieb Sauyon Lee:
I recently uploaded a sadly very broken PKGBUILD to the AUR and named it godep-git.
However, after reading the packaging guidelines, I've decided that it really should be just "godep," as the project has no releases, so I'm going to be uploading a working PKGBUILD under that name in a (hopefully) short amount of time.
Your package seems to have been deleted already, but I disagree:
If your PKGBUILD always builds the current git version (using git) then it should be named godep-git. If they start making releases another package "godep" can be created (without using git).
https://aur.archlinux.org/packages/go/godep/PKGBUILD *is* a git package.
You should at least force a specific git hash or tag to make it a stable package.
-- JonnyJD
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. 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.
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
participants (2)
-
Johannes Dewender
-
Sauyon Lee