Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#41722 - [go] Use source archive rather than full repository clone
Attached to Project:
Community Packages
Opened by Florez Brownlee (frownlee) - Wednesday, 27 August 2014, 19:17 GMT
Last edited by Alexander F. Rødseth (xyproto) - Thursday, 18 September 2014, 19:53 GMT
Opened by Florez Brownlee (frownlee) - Wednesday, 27 August 2014, 19:17 GMT
Last edited by Alexander F. Rødseth (xyproto) - Thursday, 18 September 2014, 19:53 GMT
|
DetailsDescription:
Google code provides tar.gz snapshots for hg repository tags (i.e. https://go.googlecode.com/archive/go1.3.1.tar.gz). Since the PKGBUILD isn't meant to track code changes at the changeset level, I think it makes sense to use the archives instead of a full hg clone (the snapshot is less than 10% the size and is much quicker to download). Additional info: * package version(s) * config and/or log files etc. Steps to reproduce: |
This task depends upon
Closed by Alexander F. Rødseth (xyproto)
Thursday, 18 September 2014, 19:53 GMT
Reason for closing: None
Additional comments about closing: Perhaps for a future release of Go. Perhaps.
Thursday, 18 September 2014, 19:53 GMT
Reason for closing: None
Additional comments about closing: Perhaps for a future release of Go. Perhaps.
FS#38860andFS#38597. Do you have a way to work around these using the snapshot?One think I should note is the snapshot I'm suggesting is NOT the release source tarball, but google code's automated snapshot of the hg tag. That is, the contents of that tarball are exactly the contents of an mercurial clone.
Slightly longer packaging time is a small tradeoff for fetching the source code as directly from upstream as possible.
Most users won't compile the go package themselves, but install it from [community].
If people wish to compile the go package themselves, one would think that they would prefer the very latest hg version, compiling it manually or by using the go-hg package from AUR.
I think the current situation is preferable to the proposed alternative.
Perhaps for a later version of the Go package.