<p dir="auto">by <strong>schwehr</strong>:</p>
<pre class="notranslate">Hi,

I am a packager for fink (apt-get managed packages on mac osx) and trying to get go to
work properly when installed via fink.  I could use some help getting the package setup
correctly.  I am not sure why go wants to modify files in its own tree.  Is there a
setup step that was missed?

I've modified
<a href="http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.7/stable/main/finkinfo/languages/go.info?view=log" rel="nofollow">http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.7/stable/main/finkinfo/languages/go.info?view=log</a>
to use go 1.1.2 that can be seen here:

<a href="https://sourceforge.net/p/fink/package-submissions/4378/" rel="nofollow">https://sourceforge.net/p/fink/package-submissions/4378/</a>

I'm guessing that once go is built, maybe we are missing a step where we have to run go
to build a bunch of static archives?

Thanks!
-kurt



# Mac osx 10.9 
xcodebuild -version
# Xcode 5.0.1

fink selfupdate
fink install go

fink list -i go | grep -i language
 i  go  1.1.2-1 Concurrent programming language

# Quick summary of what the info file does:

perl -pi -e 's/C.malloc\(C.size_t\(bufSize\)\)/C.malloc\(C.ulong\(bufSize\)\)/'
src/pkg/os/user/lookup_unix.go
export GOROOT_FINAL=%p/lib/go
  cd src
  ./all.bash

mkdir -p %i/lib/go/src
  cp -r bin include lib pkg %i/lib/go
  cp -r src/pkg %i/lib/go/src

 # for godoc
 ln -s ../../share/doc/go/doc %i/lib/go/doc

 mkdir %i/bin
 cd bin
 for i in *; do
    ln -s ../lib/go/bin/$i %i/bin/$i
 done


cd
mkdir go
cd go
export GOPATH=$HOME/go
export PATH=$PATH:$GOPATH/bin
mkdir -p $GOPATH/src/github.com/$USER
echo $GOPATH/src/github.com/$USER
# /Users/schwehr/go/src/github.com/schwehr
mkdir $GOPATH/src/github.com/$USER/hello

cat &lt;&lt; EOF &gt; $GOPATH/src/github.com/$USER/hello/hello.go
package main

import "fmt"

func main() {
    fmt.Printf("Hello, world.\n")
}
EOF

go build github.com/$USER/hello

go install github.com/$USER/hello
# go install errors: open /sw/lib/go/pkg/darwin_amd64/errors.a: permission denied
# go install math: open /sw/lib/go/pkg/darwin_amd64/math.a: permission denied
go version
go version go1.1.2 darwin/amd64

go env
GOARCH="amd64"
GOBIN=""
GOCHAR="6"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/schwehr/go"
GORACE=""
GOROOT="/sw/lib/go"
GOTOOLDIR="/sw/lib/go/pkg/tool/darwin_amd64"
CC="gcc"
GOGCCFLAGS="-g -O2 -fPIC -m64 -pthread -fno-common"
CGO_ENABLED="1"


# Trying to see what go wants to do:
go install -n -v github.com/schwehr/hello

errors
mkdir -p $WORK/errors/_obj/
mkdir -p $WORK/
cd /sw/lib/go/src/pkg/errors
/sw/lib/go/pkg/tool/darwin_amd64/6g -o $WORK/errors/_obj/_go_.6 -p errors -complete -D
_/sw/lib/go/src/pkg/errors -I $WORK ./errors.go
/sw/lib/go/pkg/tool/darwin_amd64/pack grcP $WORK $WORK/errors.a $WORK/errors/_obj/_go_.6
mkdir -p /sw/lib/go/pkg/darwin_amd64/
cp $WORK/errors.a /sw/lib/go/pkg/darwin_amd64/errors.a

# But that already exists!!!!
ls -l /sw/lib/go/pkg/darwin_amd64/errors.a
# -rw-r--r--  1 root  admin  6948 Nov 27 23:27 /sw/lib/go/pkg/darwin_amd64/errors.a

# Go should really not be trying to do this kind of thing!</pre>
<h1 dir="auto">Proposal: Vendor specification and experimental repository fetch code</h1>
<p dir="auto">Author(s): Daniel Theophanes</p>
<p dir="auto">Last updated: 2015-12-06</p>
<h2 dir="auto">Abstract</h2>
<p dir="auto">Establish a specification file format that lists dependency revisions and<br>
a package in the golang.org/x/exp repository that discovers, reads, and downloads<br>
packages at a given revision. Tools may continue to use other formats to generate<br>
this file.</p>
<h2 dir="auto">Background</h2>
<p dir="auto">Many developers wish to specify revisions of vendor dependencies without copying<br>
them into the repository. For a case study I will bring up two:</p>
<p dir="auto">A) <a href="https://github.com/cockroachdb/cockroach">https://github.com/cockroachdb/cockroach</a></p>
<p dir="auto">B) <a href="https://github.com/gluster/glusterd2">https://github.com/gluster/glusterd2</a></p>
<p dir="auto">(A) uses <code class="notranslate">github.com/robfig/glock</code> which specifies revisions for each remote repository<br>
in file in the project root called "GLOCKFILE". A partial list of the file is:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="cmd golang.org/x/tools/cmd/stress
cmd golang.org/x/tools/cmd/stringer
github.com/agtorre/gocolorize f42b554bf7f006936130c9bb4f971afd2d87f671
github.com/biogo/store 3b4c041f52c224ee4a44f5c8b150d003a40643a0
github.com/cockroachdb/c-rocksdb bf15ead80bdc205a19b3d33415b23c156a3cf371
github.com/cockroachdb/c-snappy 5c6d0932e0adaffce4bfca7bdf2ac37f79952ccf
github.com/cockroachdb/yacc 443154b1852a8702b07d675da6cd97cd9177a316
github.com/coreos/etcd a423a55b142c2b9a82811604204cddbccd0a9cf9"><pre class="notranslate"><code class="notranslate">cmd golang.org/x/tools/cmd/stress
cmd golang.org/x/tools/cmd/stringer
github.com/agtorre/gocolorize f42b554bf7f006936130c9bb4f971afd2d87f671
github.com/biogo/store 3b4c041f52c224ee4a44f5c8b150d003a40643a0
github.com/cockroachdb/c-rocksdb bf15ead80bdc205a19b3d33415b23c156a3cf371
github.com/cockroachdb/c-snappy 5c6d0932e0adaffce4bfca7bdf2ac37f79952ccf
github.com/cockroachdb/yacc 443154b1852a8702b07d675da6cd97cd9177a316
github.com/coreos/etcd a423a55b142c2b9a82811604204cddbccd0a9cf9
</code></pre></div>
<p dir="auto">(B) uses <code class="notranslate">github.com/Masterminds/glide</code> which specifies revisions for each remote<br>
repository in a file in the project root called "glide.yaml". This file contains:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="parent: null
package: github.com/gluster/glusterd2
import:
- package: github.com/gorilla/context
  version: 1c83b3eabd45b6d76072b66b746c20815fb2872d
- package: gopkg.in/tylerb/graceful.v1
  version: 48afeb21e2fcbcff0f30bd5ad6b97747b0fae38e
- package: github.com/pborman/uuid
  version: cccd189d45f7ac3368a0d127efb7f4d08ae0b655
- package: github.com/gorilla/mux
  version: ad4d7a5882b961e07e2626045eb995c022ac6664
- package: golang.org/x/net
  version: b4e17d61b15679caf2335da776c614169a1b4643
- package: github.com/docker/libkv
  version: 93099f38de7421e6979983652730a81e2bafd578
- package: github.com/codegangsta/negroni
  version: c7477ad8e330bef55bf1ebe300cf8aa67c492d1b
- package: golang.org/x/sys
  subpackages:
  - /unix
- package: github.com/meatballhat/negroni-logrus
  version: dd89490b0057cca7fe3fa3885f82935dfd430c2e
- package: github.com/Sirupsen/logrus
  version: v0.8.7
- package: github.com/hashicorp/consul
  version: v0.5.2"><pre class="notranslate"><code class="notranslate">parent: null
package: github.com/gluster/glusterd2
import:
- package: github.com/gorilla/context
  version: 1c83b3eabd45b6d76072b66b746c20815fb2872d
- package: gopkg.in/tylerb/graceful.v1
  version: 48afeb21e2fcbcff0f30bd5ad6b97747b0fae38e
- package: github.com/pborman/uuid
  version: cccd189d45f7ac3368a0d127efb7f4d08ae0b655
- package: github.com/gorilla/mux
  version: ad4d7a5882b961e07e2626045eb995c022ac6664
- package: golang.org/x/net
  version: b4e17d61b15679caf2335da776c614169a1b4643
- package: github.com/docker/libkv
  version: 93099f38de7421e6979983652730a81e2bafd578
- package: github.com/codegangsta/negroni
  version: c7477ad8e330bef55bf1ebe300cf8aa67c492d1b
- package: golang.org/x/sys
  subpackages:
  - /unix
- package: github.com/meatballhat/negroni-logrus
  version: dd89490b0057cca7fe3fa3885f82935dfd430c2e
- package: github.com/Sirupsen/logrus
  version: v0.8.7
- package: github.com/hashicorp/consul
  version: v0.5.2
</code></pre></div>
<p dir="auto">I would like to point out a few features these tools provide:</p>
<ul dir="auto">
<li>Specify commands to fetch.</li>
<li>Specify repositories at a given revision.</li>
<li>Specify repositories at a given version.</li>
<li>Specify a sub-tree of packages in a given repository.</li>
</ul>
<p dir="auto">Right now each vendor tool specifies these same properties in different formats.<br>
A common tool cannot be built that reads a single file and downloads the needed<br>
dependencies. This isn't a huge burden on a dedicated developer, but for a<br>
user passing by who just wants to build the source quickly, it is an impediment.</p>
<h2 dir="auto">Proposal</h2>
<p dir="auto">I propose specifying a single file format that will describe packages sourced<br>
outside the project repository. I also propose adding a packge to the<br>
golang.org/x/exp repository that discovers, reads, and optionally downloads<br>
third party packages.</p>
<p dir="auto">Furthermore I propose using the specification found at<br>
<a href="https://github.com/kardianos/vendor-spec">https://github.com/kardianos/vendor-spec</a> with one addition as the basis for this<br>
specification. The addition is:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="Package []struct {
    ...

    // Tree indicates that the specified folder, along with all sub-folders
    // are required.
    Tree bool `json:&quot;tree&quot;`

    ...
}"><pre class="notranslate"><code class="notranslate">Package []struct {
    ...

    // Tree indicates that the specified folder, along with all sub-folders
    // are required.
    Tree bool `json:"tree"`

    ...
}
</code></pre></div>
<p dir="auto">Both the specification and the proposed package will be considered experimental<br>
and subject to change or retraction until at least go1.7. This process will be<br>
done with an eye to possibly adding this feature to <code class="notranslate">go get</code>.</p>
<h2 dir="auto">Rationale</h2>
<p dir="auto">The vendor file format needs to be able to be read and written with standard<br>
go packages. This adds to the possibly that <code class="notranslate">go get</code> could fetch packages<br>
automatically.</p>
<p dir="auto">Vendor tools exist today that download packages from a specification. They are just<br>
incompatible with each other despite using the same information to download the<br>
dependencies. If we can agree on a single format for tools to write to, even if<br>
it isn't the primary format for that tool, all tools and possibly <code class="notranslate">go get</code> can<br>
download dependencies.</p>
<p dir="auto">Existing vendor tools and their formats don't always handle corner cases or<br>
different approaches. For example current tool file formats can't handle the<br>
case of vendoring a patched version of a standard library package (this<br>
would have been useful for <code class="notranslate">crypto/tls</code> forks for detecting the heartbleed<br>
attack and for accessing MS Azure).</p>
<p dir="auto">I am proposing a file format that "govendor" uses. I'm not trying to put my own<br>
tool as central. Infact, "govendor" was built to validate the "vendor-spec"<br>
proposal. The "vendor-spec" has received significant external contributions<br>
and as such "govendor" has changed to match the spec (and will continue to do so).</p>
<h2 dir="auto">Compatibility</h2>
<p dir="auto">This will be standardization of existing practices. There is no go1 compatibility<br>
issues. Existing tools can treat the specification as a write only file.</p>
<h2 dir="auto">Implementation</h2>
<p dir="auto">A file format to describe vendor packages should be accepted when this<br>
proposal is accepted. Should this proposal be accepted a new package<br>
should be added to the "golang.org/x/exp" repository to support reading<br>
the vendor file and downloading packages. The author of this proposal<br>
offers to create or assist in creating this package. This would be created<br>
within 2 months of the proposal being accepted.</p>
<h2 dir="auto">Risks</h2>
<p dir="auto">It would be ideal if other vendor tool package authors could agree to at least<br>
write to a standard file format informally and collaboratively. Indeed the largest<br>
risk is if vendor tools fail to write the common file format. However I think<br>
unless there is a tangible benefit (such as <code class="notranslate">go get</code> support) there will continue<br>
to not be a reason to collaborate on a standard.</p>
<h2 dir="auto">Open issues</h2>
<p dir="auto">The proposed standard file format uses JSON, which might be better then XML, but<br>
harder to write by then something like TOML. Tools that want the vendor file<br>
to be hand created will be forced to generate this file from a different file.</p>
<p dir="auto">The file format specifies packages, not repositories. Repositories can be specified<br>
by using the root path to the repository and specifying <code class="notranslate">"tree": true</code>, but it isn't<br>
the default for the format. Some people may take issue with that as they are used<br>
to or desire tools that only work at the repository level. This could be a point<br>
of division. From experience I absolutely love vendoring at the package level<br>
(this is what github.com/kardianos/govendor does by default).</p>