[gentoo-dev] dev-lang/go

[gentoo-dev] dev-lang/go

[Emery Hemingway]

I really like working with Go, and would like to see a means of merging
Go packages with Portage. In short I am asking if anyone else is
interested in a Go project.


For those who aren't familiar with Go, I will sumarise why Portage and
Go do not play well together.

Go is static linked by default.
The Go compiler creates static libraries and binaries. Libraries
compilied with different versions of Go (1.1/1.2) may not be linked
into the same binary.

It is possible to compile dynamicly and that may involve using the
GCC frontend, which is probably less tested and less optimized.


Go libraries are usually unversioned.
Libraries outside the system library are resolved with an import
statement that specifies a source code repository, such as a git or
mecurial repository. Most often Go libraries are installed using the
'go get' tool that clones a repository, and simply assumes HEAD/tip is
the best revision to build against. There is some support for using git
tags but it is not well documented. Often these libraries are very
small for the sake of reuse and to keep APIs simple.

If all that sounds bad, thats because it is. Is it worth versioning
many tiny libraries or do we simply cache the repositiories and blame
upstream when things stop compiling?


A have made an eclass for Go and an ebuild for the bitcoin node written
in pure Go to atleast prove that all this is possible. These are in the
'emery' overlay:
http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=eclass
http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=dev-go
http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=net-p2p/btcd

The eclass it a bit of a mess but it works, having done that, I would
say that making ebuilds for every go library is tedious, but can be
done almost entirely with boilerplate, almost every time.

The eclasss installs go source and static libraries
to /usr/lib/go/gentoo (source code and .a library are required to link).
The problem is when Go is updated, this folder may get wiped out, and
if it isn't, those libraries will be incompatable with the new release
anyway.

The other solution I see is to make a Go directory in /var/cache or
something like it and just manage it as a cache. Libraries may come and
go but that is fine. Bare repositories may be cached in DISTDIR just
like the git and mercurial eclasses do. Doing things this way may
require a specific utility for Portage that wraps the Go toolchain,
which I would be willing to create. This utility could probably
automatically resolve and fetch the libraries that are required as
opposed to making an ebuild for each library, but that raises the
problem of assuming the developers of each library maintain consistant
quality and security.


The problem is Go makes it trivial to build from source, but it does
that in a very different and less precise way than Gentoo. There is
always the option of build bots and installing binaries to /opt...


Emery

Re: [gentoo-dev] dev-lang/go

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/30/2013 03:48 PM, Emery Hemingway wrote:
> I really like working with Go, and would like to see a means of merging
> Go packages with Portage. In short I am asking if anyone else is
> interested in a Go project.
> 
> 
> For those who aren't familiar with Go, I will sumarise why Portage and
> Go do not play well together.

You can fine go-mtpfs in portage already.  I packaged it, with a lot of
help. It's terrible.  Worst part, it can't reinstall.  You can install,
and uninstall, but if it is installed you can't install again (so emerge
- -e @world would fail).

By all means, have fun.

- -Zero

> 
> Go is static linked by default.
> The Go compiler creates static libraries and binaries. Libraries
> compilied with different versions of Go (1.1/1.2) may not be linked
> into the same binary.
> 
> It is possible to compile dynamicly and that may involve using the
> GCC frontend, which is probably less tested and less optimized.
> 
> 
> Go libraries are usually unversioned.
> Libraries outside the system library are resolved with an import
> statement that specifies a source code repository, such as a git or
> mecurial repository. Most often Go libraries are installed using the
> 'go get' tool that clones a repository, and simply assumes HEAD/tip is
> the best revision to build against. There is some support for using git
> tags but it is not well documented. Often these libraries are very
> small for the sake of reuse and to keep APIs simple.
> 
> If all that sounds bad, thats because it is. Is it worth versioning
> many tiny libraries or do we simply cache the repositiories and blame
> upstream when things stop compiling?
> 
> 
> A have made an eclass for Go and an ebuild for the bitcoin node written
> in pure Go to atleast prove that all this is possible. These are in the
> 'emery' overlay:
> http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=eclass
> http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=dev-go
> http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=net-p2p/btcd
> 
> The eclass it a bit of a mess but it works, having done that, I would
> say that making ebuilds for every go library is tedious, but can be
> done almost entirely with boilerplate, almost every time.
> 
> The eclasss installs go source and static libraries
> to /usr/lib/go/gentoo (source code and .a library are required to link).
> The problem is when Go is updated, this folder may get wiped out, and
> if it isn't, those libraries will be incompatable with the new release
> anyway.
> 
> The other solution I see is to make a Go directory in /var/cache or
> something like it and just manage it as a cache. Libraries may come and
> go but that is fine. Bare repositories may be cached in DISTDIR just
> like the git and mercurial eclasses do. Doing things this way may
> require a specific utility for Portage that wraps the Go toolchain,
> which I would be willing to create. This utility could probably
> automatically resolve and fetch the libraries that are required as
> opposed to making an ebuild for each library, but that raises the
> problem of assuming the developers of each library maintain consistant
> quality and security.
> 
> 
> The problem is Go makes it trivial to build from source, but it does
> that in a very different and less precise way than Gentoo. There is
> always the option of build bots and installing binaries to /opt...
> 
> 
> Emery
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSweOYAAoJEKXdFCfdEflKaf4QAK2JNcVGg4eSvVXpkkgdwKlO
xp3Dm8ao6Ly/DuqD1wSQUghsaCaw9yD0bzlnLOwGQkHhFhAxqj/wpyLdKAr6rQ64
YqtT5WIFdymuB/rSO+0D47zfyjQeFLUGbiiSLMTrTyqol2SexchlVu6mLKLDM0rX
pJctl4iERzHKHF7/xdQv90vBkUgQsRlN/YlGYUXO/6P5CDJU+T2+rGlps7yN/z+h
oaZrVJxNHExdTCbIhnpfKOVSiBisVG2dlwJKL0FFq9EhJph+hrxe9CaD8rMNKGkL
Suc/6rT4vFmBmb32/Lzy4x9dfxD6n12vwQBn8ZctJnoqfniVx96S4xmwrBtG3hNH
7JenDriuVUuIkUut45+okBUu829PDt0qs+LRRBQejf4DdnkFKJGg1W+97IwVGlTc
J/qz+sEdoLTD88zd145iMf79TonmDwDxGxoDEiGs69250TC0WWWnP0x799p0S7uq
+2iOunm2oRB2HAiGg/T/rC+C00/pE441ZWX/zXtDphVe3oOsQ8ieZOL/U62+vb6e
/VaUp9iTQrssRvRuIpvC0Oqt+2YGlUQHFEAHb/5HHTBFhrdZLyC3edai7+VNIEy3
UV6B82MY5sUDhHPY+b2RpVlrkuhN7AqZWebI7qapVzU3gg8liyE8LWW6uvgz7wTF
8BWuxvBPwaP/1RczKaeV
=Yv0m
-----END PGP SIGNATURE-----

[gentoo-dev] Re: dev-lang/go

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

On Mon, 30 Dec 2013 15:48:17 -0500
Emery Hemingway <emery@vfemail.net> wrote:

> I really like working with Go, and would like to see a means of merging
> Go packages with Portage. In short I am asking if anyone else is
> interested in a Go project.
> 
> 
> For those who aren't familiar with Go, I will sumarise why Portage and
> Go do not play well together.

What's wrong with gccgo?  (serious question, other than making sure it builds
I haven't used it).


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] dev-lang/go

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 3583 bytes --]

On Mon, Dec 30, 2013 at 12:48 PM, Emery Hemingway <emery@vfemail.net> wrote:

> I really like working with Go, and would like to see a means of merging
> Go packages with Portage. In short I am asking if anyone else is
> interested in a Go project.
>
>
> For those who aren't familiar with Go, I will sumarise why Portage and
> Go do not play well together.
>
> Go is static linked by default.
> The Go compiler creates static libraries and binaries. Libraries
> compilied with different versions of Go (1.1/1.2) may not be linked
> into the same binary.
>
> It is possible to compile dynamicly and that may involve using the
> GCC frontend, which is probably less tested and less optimized.
>
>
> Go libraries are usually unversioned.
> Libraries outside the system library are resolved with an import
> statement that specifies a source code repository, such as a git or
> mecurial repository. Most often Go libraries are installed using the
> 'go get' tool that clones a repository, and simply assumes HEAD/tip is
> the best revision to build against. There is some support for using git
> tags but it is not well documented. Often these libraries are very
> small for the sake of reuse and to keep APIs simple.
>
> If all that sounds bad, thats because it is. Is it worth versioning
> many tiny libraries or do we simply cache the repositiories and blame
> upstream when things stop compiling?
>
>
> A have made an eclass for Go and an ebuild for the bitcoin node written
> in pure Go to atleast prove that all this is possible. These are in the
> 'emery' overlay:
> http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=eclass
> http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=dev-go
>
> http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=net-p2p/btcd
>
> The eclass it a bit of a mess but it works, having done that, I would
> say that making ebuilds for every go library is tedious, but can be
> done almost entirely with boilerplate, almost every time.
>
>
Don't we basically do this with perl and g-cpan?


> The eclasss installs go source and static libraries
> to /usr/lib/go/gentoo (source code and .a library are required to link).
> The problem is when Go is updated, this folder may get wiped out, and
> if it isn't, those libraries will be incompatable with the new release
> anyway.
>

Can we version the shared objects in the golang they were compiled for?

/usr/lib/go/gentoo/GO_TOOLCHAIN_VERSION/...


>
> The other solution I see is to make a Go directory in /var/cache or
> something like it and just manage it as a cache. Libraries may come and
> go but that is fine. Bare repositories may be cached in DISTDIR just
> like the git and mercurial eclasses do. Doing things this way may
> require a specific utility for Portage that wraps the Go toolchain,
> which I would be willing to create. This utility could probably
> automatically resolve and fetch the libraries that are required as
> opposed to making an ebuild for each library, but that raises the
> problem of assuming the developers of each library maintain consistant
> quality and security.
>

I feel like this is not a great idea. What your idea as proposed reads like
to me is 'hey i want to move some libraries into /var/cache..cause you
know...we can delete the libraries at any time...and we can just recompile
them!'


>
>
> The problem is Go makes it trivial to build from source, but it does
> that in a very different and less precise way than Gentoo. There is
> always the option of build bots and installing binaries to /opt...
>
>
> Emery
>
>

[-- Attachment #2: Type: text/html, Size: 4971 bytes --]

Re: [gentoo-dev] dev-lang/go

[yac]

[-- Attachment #1: Type: text/plain, Size: 5370 bytes --]

On Mon, 30 Dec 2013 15:48:17 -0500
Emery Hemingway <emery@vfemail.net> wrote:

> I really like working with Go, and would like to see a means of
> merging Go packages with Portage. In short I am asking if anyone else
> is interested in a Go project.

I might be. I have packaged something for private use but it just a
bunch of hacks. Anyway, I have some production go code.

>
> For those who aren't familiar with Go, I will sumarise why Portage and
> Go do not play well together.
>
> Go is static linked by default.
> The Go compiler creates static libraries and binaries. Libraries
> compilied with different versions of Go (1.1/1.2) may not be linked
> into the same binary.

Haskell is staticaly linked as well (by default) and you can see the
gentoo haskell project. I don't see this as a problem, we just will have
all dependencies in DEPEND and will have to scope on the go compiler
version under something like /usr/lib/go-1.{1,2}/...

I'd just copy the python herd approach (use flags, filesystem scoping
and having binary wrapper).

> It is possible to compile dynamicly and that may involve using the
> GCC frontend, which is probably less tested and less optimized.

I'd just skip over this unless someone is really interested in this one,
in which case this could be explicitly enabled by a use flag or
something.

>
> Go libraries are usually unversioned.
> Libraries outside the system library are resolved with an import
> statement that specifies a source code repository, such as a git or
> mecurial repository. Most often Go libraries are installed using the
> 'go get' tool that clones a repository, and simply assumes HEAD/tip is
> the best revision to build against. There is some support for using
> git tags but it is not well documented. Often these libraries are very
> small for the sake of reuse and to keep APIs simple.

In this case we just have to require upstream to make releases or
publish either live ebuilds, or ebuilds versioned something like
0_preYYYY-MM-DD.ebuild [1]

I know part of the gopher commnity doesn't see this as a problem but I
believe the big players recognize this and there is an effort to come up
with a solution.

> If all that sounds bad, thats because it is. Is it worth versioning
> many tiny libraries or do we simply cache the repositiories and blame
> upstream when things stop compiling?

I'd certainly want to have versions where available.

>
> A have made an eclass for Go and an ebuild for the bitcoin node
> written in pure Go to atleast prove that all this is possible. These
> are in the 'emery' overlay:
> http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=eclass
> http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=dev-go
> http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=net-p2p/btcd
>
> The eclass it a bit of a mess but it works, having done that, I would
> say that making ebuilds for every go library is tedious, but can be
> done almost entirely with boilerplate, almost every time.
>
> The eclasss installs go source and static libraries
> to /usr/lib/go/gentoo (source code and .a library are required to
> link). The problem is when Go is updated, this folder may get wiped
> out, and if it isn't, those libraries will be incompatable with the
> new release anyway.

How come it gets wiped? That just shouldn't happen.

> The other solution I see is to make a Go directory in /var/cache or

I don't think this is a good idea as I think it would be surprising to
users to find libraries elsewhere than /usr/lib and I believe /var/cache
specificaly even violates FHS.

> something like it and just manage it as a cache.
> Libraries may come and go but that is fine.

I might want to have a library just for development and I'd wouldn't
like it disappearing.

> Bare repositories may be cached in DISTDIR
> just like the git and mercurial eclasses do. Doing things this way may
> require a specific utility for Portage that wraps the Go toolchain,
> which I would be willing to create. This utility could probably
> automatically resolve and fetch the libraries that are required

Building the library/package shouldn't/mustn't (what does the PMS
say?) require network access once the sources are fetched.

> as opposed to making an ebuild for each library, but that raises the
> problem of assuming the developers of each library maintain consistant
> quality and security.

Every ebuild that gets to gentoo official must meet basic standard of
quality. That's no different for golang.

>
>
> The problem is Go makes it trivial to build from source, but it does
> that in a very different and less precise way than Gentoo. There is
> always the option of build bots and installing binaries to /opt...
>
>
> Emery
>

I think it would be good idea to start a separate gentoo-golang
repository (github?) and treat it more (to keep it aligned with the way
gentoo works) or less (to speed up the development) as if it were gx86.

In the organization part, I think we could inspire ourself in the way
gentoo-haskell works.

[1]: http://devmanual.gentoo.org/ebuild-writing/file-format/

---
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] dev-lang/go

[Emery Hemingway]

> I think it would be good idea to start a separate gentoo-golang
> repository (github?) and treat it more (to keep it aligned with the
> way gentoo works) or less (to speed up the development) as if it were
> gx86.
> 
> In the organization part, I think we could inspire ourself in the way
> gentoo-haskell works.
> 
> Jan Matějka        | Gentoo Developer
> https://gentoo.org | Gentoo Linux
> GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B

Thanks the comments, I'm not familar with what portage does with haskel
so I'll take a look.

I'll collect the notes that have been made here and start a project on
github or gitorious in the next few days and post the details here.

Emery

Re: [gentoo-dev] dev-lang/go

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 3137 bytes --]

Hi all,

I responded to this a while back, but I guess my email didn't go out for
some reason.

As the primary go maintainer, I do want to be involved in this. :-)

On Tue, Feb 11, 2014 at 01:38:44AM +0100, yac wrote:
> On Mon, 30 Dec 2013 15:48:17 -0500
> Emery Hemingway <emery@vfemail.net> wrote:
> 
> > I really like working with Go, and would like to see a means of
> > merging Go packages with Portage. In short I am asking if anyone else
> > is interested in a Go project.
> 
> I might be. I have packaged something for private use but it just a
> bunch of hacks. Anyway, I have some production go code.
> 
> >
> > For those who aren't familiar with Go, I will sumarise why Portage and
> > Go do not play well together.
> >
> > Go is static linked by default.
> > The Go compiler creates static libraries and binaries. Libraries
> > compilied with different versions of Go (1.1/1.2) may not be linked
> > into the same binary.
> 
> Haskell is staticaly linked as well (by default) and you can see the
> gentoo haskell project. I don't see this as a problem, we just will have
> all dependencies in DEPEND and will have to scope on the go compiler
> version under something like /usr/lib/go-1.{1,2}/...

That could be done easily enough, but what about the tools in /usr/bin
(there aren't many, but there are a couple), and these do not change
name with each version of go.

> > Go libraries are usually unversioned.
> > Libraries outside the system library are resolved with an import
> > statement that specifies a source code repository, such as a git or
> > mecurial repository. Most often Go libraries are installed using the
> > 'go get' tool that clones a repository, and simply assumes HEAD/tip is
> > the best revision to build against. There is some support for using
> > git tags but it is not well documented. Often these libraries are very
> > small for the sake of reuse and to keep APIs simple.

My understanding is that a library repo will have branches based on the
version of go, so for example, it might have a branch called go-1 which
will be where go get will look to find the latest version of the code
that works with go-1.x.

> In this case we just have to require upstream to make releases or
> publish either live ebuilds, or ebuilds versioned something like
> 0_preYYYY-MM-DD.ebuild [1]

I don't think we are going to be able to require upstream to make
releases, so that leaves us with:

1) using live ebuilds, which will never be allowed to have keywords by
gentoo policy, or
2) publishing snapshots, which also means we have to create tarballs to
match them. This will be a lot of work for us as maintainers. Also, the
only way we will know when a new "version" of the library is released is
to closely monitor the upstream git repository.

The other concern, which I believe zero was talking about is, once a
library is installed in GOPATH, I don't think the go build system
rebuilds it. In other words, "go get" will see that it is already there
and I don't think it goes back out to the net to check for any changes.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] dev-lang/go

[Emery Hemingway]

I made an overlay for Go eclasses and packages:
https://github.com/gentoo-golang/overlay

If anyone is interested ping 'emery' in #gentoo-dev-help and I'll add
you to the github organization.

There is an overlay skeleton at master, and a first draft eclass and
ebuilds for btcd on another branch. I'll start adding what was
discussed here as issues on the repo.

Emery

Re: [gentoo-dev] dev-lang/go

[Jan Matejka]

[-- Attachment #1: Type: text/plain, Size: 4206 bytes --]

On Thu, 13 Feb 2014 11:59:16 -0600
William Hubbs <williamh@gentoo.org> wrote:

> Hi all,
> 
> I responded to this a while back, but I guess my email didn't go out
> for some reason.
> 
> As the primary go maintainer, I do want to be involved in this. :-)
> 
> On Tue, Feb 11, 2014 at 01:38:44AM +0100, yac wrote:
> > On Mon, 30 Dec 2013 15:48:17 -0500
> > Emery Hemingway <emery@vfemail.net> wrote:
> > 
> > > I really like working with Go, and would like to see a means of
> > > merging Go packages with Portage. In short I am asking if anyone
> > > else is interested in a Go project.
> > 
> > I might be. I have packaged something for private use but it just a
> > bunch of hacks. Anyway, I have some production go code.
> > 
> > >
> > > For those who aren't familiar with Go, I will sumarise why
> > > Portage and Go do not play well together.
> > >
> > > Go is static linked by default.
> > > The Go compiler creates static libraries and binaries. Libraries
> > > compilied with different versions of Go (1.1/1.2) may not be
> > > linked into the same binary.
> > 
> > Haskell is staticaly linked as well (by default) and you can see the
> > gentoo haskell project. I don't see this as a problem, we just will
> > have all dependencies in DEPEND and will have to scope on the go
> > compiler version under something like /usr/lib/go-1.{1,2}/...
> 
> That could be done easily enough, but what about the tools in /usr/bin
> (there aren't many, but there are a couple), and these do not change
> name with each version of go.

Please see what python does for different python versions (which you
omitted from my previous email).

> > > Go libraries are usually unversioned.
> > > Libraries outside the system library are resolved with an import
> > > statement that specifies a source code repository, such as a git
> > > or mecurial repository. Most often Go libraries are installed
> > > using the 'go get' tool that clones a repository, and simply
> > > assumes HEAD/tip is the best revision to build against. There is
> > > some support for using git tags but it is not well documented.
> > > Often these libraries are very small for the sake of reuse and to
> > > keep APIs simple.
> 
> My understanding is that a library repo will have branches based on
> the version of go, so for example, it might have a branch called go-1
> which will be where go get will look to find the latest version of
> the code that works with go-1.x.
> 
> > In this case we just have to require upstream to make releases or
> > publish either live ebuilds, or ebuilds versioned something like
> > 0_preYYYY-MM-DD.ebuild [1]
> 
> I don't think we are going to be able to require upstream to make
> releases, so that leaves us with:
>
> 1) using live ebuilds, which will never be allowed to have keywords by
> gentoo policy, or
> 2) publishing snapshots, which also means we have to create tarballs
> to match them. This will be a lot of work for us as maintainers.
> Also, the only way we will know when a new "version" of the library
> is released is to closely monitor the upstream git repository.

As I said in previous email, I think at least part of go community sees
this as an issue and this is something we can not solve right now but
rather need to work on this on case-by-case basis.

Some upstreams may be willing to do releases / follow semver.org or
something like that. But there will also be upstream which won't and
that's fine, we should be able to handle both cases.

Anyway, asking the upstream to do a release is simple enough and you
won't know until you ask.
 
> The other concern, which I believe zero was talking about is, once a
> library is installed in GOPATH, I don't think the go build system
> rebuilds it. In other words, "go get" will see that it is already
> there and I don't think it goes back out to the net to check for any
> changes.

I think when doing a `go build` it will check if newer version is
available and print a warning.

> William
> 



--
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] dev-lang/go

[Emery Hemingway]

On Fri, 14 Feb 2014 13:30:10 +0100
Jan Matejka <yac@gentoo.org> wrote:

> On Thu, 13 Feb 2014 11:59:16 -0600
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > Hi all,
> > 
> > I responded to this a while back, but I guess my email didn't go out
> > for some reason.
> > 
> > As the primary go maintainer, I do want to be involved in this. :-)
> > 
> > On Tue, Feb 11, 2014 at 01:38:44AM +0100, yac wrote:
> > > On Mon, 30 Dec 2013 15:48:17 -0500
> > > Emery Hemingway <emery@vfemail.net> wrote:
> > > 
> > > > I really like working with Go, and would like to see a means of
> > > > merging Go packages with Portage. In short I am asking if anyone
> > > > else is interested in a Go project.
> > > 
> > > I might be. I have packaged something for private use but it just
> > > a bunch of hacks. Anyway, I have some production go code.
> > > 
> > > >
> > > > For those who aren't familiar with Go, I will sumarise why
> > > > Portage and Go do not play well together.
> > > >
> > > > Go is static linked by default.
> > > > The Go compiler creates static libraries and binaries. Libraries
> > > > compilied with different versions of Go (1.1/1.2) may not be
> > > > linked into the same binary.
> > > 
> > > Haskell is staticaly linked as well (by default) and you can see
> > > the gentoo haskell project. I don't see this as a problem, we
> > > just will have all dependencies in DEPEND and will have to scope
> > > on the go compiler version under something
> > > like /usr/lib/go-1.{1,2}/...
> > 
> > That could be done easily enough, but what about the tools
> > in /usr/bin (there aren't many, but there are a couple), and these
> > do not change name with each version of go.
> 
> Please see what python does for different python versions (which you
> omitted from my previous email).
> 

I've modified the go-1.2 ebuild to install to usr/lib/go1.2 and I'm
working on an eselect module to manage the symlink to usr/bin/[go,gofmt]

The default GOROOT that go looks at for base libraries seems to be
compiled in so this should be pretty easy, like python but simplier.

An eclass could look at a GO_MINIMUM variable and install for each
version go that is present and matches. Dropping old versions of go
will be easy because linking wont break, and new releases should be
forwards compatible. Maybe 3rd party library sources could be stored in
a version agnostic directory and symlinked in to usr/lib/goX.X/gentoo
to deduplicate the files?

> > > > Go libraries are usually unversioned.
> > > > Libraries outside the system library are resolved with an import
> > > > statement that specifies a source code repository, such as a git
> > > > or mecurial repository. Most often Go libraries are installed
> > > > using the 'go get' tool that clones a repository, and simply
> > > > assumes HEAD/tip is the best revision to build against. There is
> > > > some support for using git tags but it is not well documented.
> > > > Often these libraries are very small for the sake of reuse and
> > > > to keep APIs simple.
> > 
> > My understanding is that a library repo will have branches based on
> > the version of go, so for example, it might have a branch called
> > go-1 which will be where go get will look to find the latest
> > version of the code that works with go-1.x.
> > 
> > > In this case we just have to require upstream to make releases or
> > > publish either live ebuilds, or ebuilds versioned something like
> > > 0_preYYYY-MM-DD.ebuild [1]
> > 
> > I don't think we are going to be able to require upstream to make
> > releases, so that leaves us with:
> >
> > 1) using live ebuilds, which will never be allowed to have keywords
> > by gentoo policy, or
> > 2) publishing snapshots, which also means we have to create tarballs
> > to match them. This will be a lot of work for us as maintainers.
> > Also, the only way we will know when a new "version" of the library
> > is released is to closely monitor the upstream git repository.
> 
> As I said in previous email, I think at least part of go community
> sees this as an issue and this is something we can not solve right
> now but rather need to work on this on case-by-case basis.
> 
> Some upstreams may be willing to do releases / follow semver.org or
> something like that. But there will also be upstream which won't and
> that's fine, we should be able to handle both cases.
> 
> Anyway, asking the upstream to do a release is simple enough and you
> won't know until you ask.
>  
> > The other concern, which I believe zero was talking about is, once a
> > library is installed in GOPATH, I don't think the go build system
> > rebuilds it. In other words, "go get" will see that it is already
> > there and I don't think it goes back out to the net to check for any
> > changes.
> 
> I think when doing a `go build` it will check if newer version is
> available and print a warning.
>
We may have to make some sort of utitilty to parse sources and check
for updates, and roll tarballs to mirror.
> 
> > William
> > 
> 
> 
> 
> --
> Jan Matějka        | Gentoo Developer
> https://gentoo.org | Gentoo Linux
> GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B

Re: [gentoo-dev] dev-lang/go

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 3233 bytes --]

On Fri, Feb 14, 2014 at 11:02:49AM -0500, Emery Hemingway wrote:
> On Fri, 14 Feb 2014 13:30:10 +0100
> Jan Matejka <yac@gentoo.org> wrote:
> 
> > On Thu, 13 Feb 2014 11:59:16 -0600
> > William Hubbs <williamh@gentoo.org> wrote:
> > 
> > > Hi all,
> > > 
> > > I responded to this a while back, but I guess my email didn't go out
> > > for some reason.
> > > 
> > > As the primary go maintainer, I do want to be involved in this. :-)
> > > 
> > > On Tue, Feb 11, 2014 at 01:38:44AM +0100, yac wrote:
> > > > On Mon, 30 Dec 2013 15:48:17 -0500
> > > > Emery Hemingway <emery@vfemail.net> wrote:
> > > > 
> > > > > I really like working with Go, and would like to see a means of
> > > > > merging Go packages with Portage. In short I am asking if anyone
> > > > > else is interested in a Go project.
> > > > 
> > > > I might be. I have packaged something for private use but it just
> > > > a bunch of hacks. Anyway, I have some production go code.
> > > > 
> > > > >
> > > > > For those who aren't familiar with Go, I will sumarise why
> > > > > Portage and Go do not play well together.
> > > > >
> > > > > Go is static linked by default.
> > > > > The Go compiler creates static libraries and binaries. Libraries
> > > > > compilied with different versions of Go (1.1/1.2) may not be
> > > > > linked into the same binary.
> > > > 
> > > > Haskell is staticaly linked as well (by default) and you can see
> > > > the gentoo haskell project. I don't see this as a problem, we
> > > > just will have all dependencies in DEPEND and will have to scope
> > > > on the go compiler version under something
> > > > like /usr/lib/go-1.{1,2}/...
> > > 
> > > That could be done easily enough, but what about the tools
> > > in /usr/bin (there aren't many, but there are a couple), and these
> > > do not change name with each version of go.
> > 
> > Please see what python does for different python versions (which you
> > omitted from my previous email).

I omitted it, because thinking about it, we don't need to worry about
this. There isn't a reason you would want go 1.1 and go 1.2 on your
system. Source level compatibility is guaranteed for all go1 programs
[1].

> I've modified the go-1.2 ebuild to install to usr/lib/go1.2 and I'm
> working on an eselect module to manage the symlink to usr/bin/[go,gofmt]

I would just install to /usr/lib/go1 and not worry about the eselect
module; there should not be a need to keep several versions of go1
around, again, because go1.x releases will be source compatible.

We could even just leave this as /usr/lib/go, because upstream doesn't
even know if a go-2 specification will happen.

> The default GOROOT that go looks at for base libraries seems to be
> compiled in so this should be pretty easy, like python but simplier.

It looks for standard libraries in GOROOT_FINAL which is set in the
ebuild and compiled into the binaries.

Third party libraries are interesting in this case, because, all of the
third party libraries we install will not be usable once the user
upgrades from say go-1.2 to go-1.3. However, rebuilding those libraries
from source will work.

William

[1] http://golang.org/doc/go1compat

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] dev-lang/go

[Emery Hemingway]

On Fri, 14 Feb 2014 17:13:27 -0600
William Hubbs <williamh@gentoo.org> wrote:

> On Fri, Feb 14, 2014 at 11:02:49AM -0500, Emery Hemingway wrote:
> > On Fri, 14 Feb 2014 13:30:10 +0100
> > Jan Matejka <yac@gentoo.org> wrote:
> > 
> > > On Thu, 13 Feb 2014 11:59:16 -0600
> > > William Hubbs <williamh@gentoo.org> wrote:
> > > 
> > > > Hi all,
> > > > 
> > > > I responded to this a while back, but I guess my email didn't
> > > > go out for some reason.
> > > > 
> > > > As the primary go maintainer, I do want to be involved in
> > > > this. :-)
> > > > 
> > > > On Tue, Feb 11, 2014 at 01:38:44AM +0100, yac wrote:
> > > > > On Mon, 30 Dec 2013 15:48:17 -0500
> > > > > Emery Hemingway <emery@vfemail.net> wrote:
> > > > > 
> > > > > > I really like working with Go, and would like to see a
> > > > > > means of merging Go packages with Portage. In short I am
> > > > > > asking if anyone else is interested in a Go project.
> > > > > 
> > > > > I might be. I have packaged something for private use but it
> > > > > just a bunch of hacks. Anyway, I have some production go code.
> > > > > 
> > > > > >
> > > > > > For those who aren't familiar with Go, I will sumarise why
> > > > > > Portage and Go do not play well together.
> > > > > >
> > > > > > Go is static linked by default.
> > > > > > The Go compiler creates static libraries and binaries.
> > > > > > Libraries compilied with different versions of Go (1.1/1.2)
> > > > > > may not be linked into the same binary.
> > > > > 
> > > > > Haskell is staticaly linked as well (by default) and you can
> > > > > see the gentoo haskell project. I don't see this as a
> > > > > problem, we just will have all dependencies in DEPEND and
> > > > > will have to scope on the go compiler version under something
> > > > > like /usr/lib/go-1.{1,2}/...
> > > > 
> > > > That could be done easily enough, but what about the tools
> > > > in /usr/bin (there aren't many, but there are a couple), and
> > > > these do not change name with each version of go.
> > > 
> > > Please see what python does for different python versions (which
> > > you omitted from my previous email).
> 
> I omitted it, because thinking about it, we don't need to worry about
> this. There isn't a reason you would want go 1.1 and go 1.2 on your
> system. Source level compatibility is guaranteed for all go1 programs
> [1].
> 
> > I've modified the go-1.2 ebuild to install to usr/lib/go1.2 and I'm
> > working on an eselect module to manage the symlink to
> > usr/bin/[go,gofmt]
> 
> I would just install to /usr/lib/go1 and not worry about the eselect
> module; there should not be a need to keep several versions of go1
> around, again, because go1.x releases will be source compatible.
> 
> We could even just leave this as /usr/lib/go, because upstream doesn't
> even know if a go-2 specification will happen.
> 
> > The default GOROOT that go looks at for base libraries seems to be
> > compiled in so this should be pretty easy, like python but simplier.
> 
> It looks for standard libraries in GOROOT_FINAL which is set in the
> ebuild and compiled into the binaries.
> 
> Third party libraries are interesting in this case, because, all of
> the third party libraries we install will not be usable once the user
> upgrades from say go-1.2 to go-1.3. However, rebuilding those
> libraries from source will work.
> 
> William
> 
> [1] http://golang.org/doc/go1compat

The reason I thought go should be slotting was that all compliled
libraries would break when go was replaced.

Mabye the only the library source could be installed, and a cache of
compiled libraries could be overlayed over that...

Re: [gentoo-dev] dev-lang/go

[yac]

[-- Attachment #1: Type: text/plain, Size: 6668 bytes --]

On Fri, 14 Feb 2014 11:02:49 -0500
Emery Hemingway <emery@vfemail.net> wrote:

> On Fri, 14 Feb 2014 13:30:10 +0100
> Jan Matejka <yac@gentoo.org> wrote:
> 
> > On Thu, 13 Feb 2014 11:59:16 -0600
> > William Hubbs <williamh@gentoo.org> wrote:
> > 
> > > Hi all,
> > > 
> > > I responded to this a while back, but I guess my email didn't go
> > > out for some reason.
> > > 
> > > As the primary go maintainer, I do want to be involved in
> > > this. :-)
> > > 
> > > On Tue, Feb 11, 2014 at 01:38:44AM +0100, yac wrote:
> > > > On Mon, 30 Dec 2013 15:48:17 -0500
> > > > Emery Hemingway <emery@vfemail.net> wrote:
> > > > 
> > > > > I really like working with Go, and would like to see a means
> > > > > of merging Go packages with Portage. In short I am asking if
> > > > > anyone else is interested in a Go project.
> > > > 
> > > > I might be. I have packaged something for private use but it
> > > > just a bunch of hacks. Anyway, I have some production go code.
> > > > 
> > > > >
> > > > > For those who aren't familiar with Go, I will sumarise why
> > > > > Portage and Go do not play well together.
> > > > >
> > > > > Go is static linked by default.
> > > > > The Go compiler creates static libraries and binaries.
> > > > > Libraries compilied with different versions of Go (1.1/1.2)
> > > > > may not be linked into the same binary.
> > > > 
> > > > Haskell is staticaly linked as well (by default) and you can see
> > > > the gentoo haskell project. I don't see this as a problem, we
> > > > just will have all dependencies in DEPEND and will have to scope
> > > > on the go compiler version under something
> > > > like /usr/lib/go-1.{1,2}/...
> > > 
> > > That could be done easily enough, but what about the tools
> > > in /usr/bin (there aren't many, but there are a couple), and these
> > > do not change name with each version of go.
> > 
> > Please see what python does for different python versions (which you
> > omitted from my previous email).
> > 
> 
> I've modified the go-1.2 ebuild to install to usr/lib/go1.2 and I'm
> working on an eselect module to manage the symlink to
> usr/bin/[go,gofmt]
> 
> The default GOROOT that go looks at for base libraries seems to be
> compiled in so this should be pretty easy, like python but simplier.

I'm not sure what you are trying to solve here. Afaik GOROOT is used to
determine where to install and it can be overriden from env.

> An eclass could look at a GO_MINIMUM variable and install for each
> version go that is present and matches.

It might be good idea to learn from others who'd been through this and
I think the new python eclasses are good ones, going with something
like PYTHON_TARGETS array (GOLANG_TARGETS ?)

> Dropping old versions of go
> will be easy because linking wont break, and new releases should be
> forwards compatible.

So far yes I think but I guess that may be quite different with in the
future with >1.x, and "should be" so there may be corner cases where the
user does need to use earlier version.

> Maybe 3rd party library sources could be stored
> in a version agnostic directory and symlinked in to
> usr/lib/goX.X/gentoo to deduplicate the files?

I'm not sure this is a good idea either. Disk space is cheap and 
doing this would only require adding special case handling code which
would get even more complicated when doing upgrades or the situation
changes (eg. main golang version).

Also keep in mind, the main golang version should not be just "1.1" but
rather "go1.1" as you may also want to choose "gcc<something>".

> > > > > Go libraries are usually unversioned.
> > > > > Libraries outside the system library are resolved with an
> > > > > import statement that specifies a source code repository,
> > > > > such as a git or mecurial repository. Most often Go libraries
> > > > > are installed using the 'go get' tool that clones a
> > > > > repository, and simply assumes HEAD/tip is the best revision
> > > > > to build against. There is some support for using git tags
> > > > > but it is not well documented. Often these libraries are very
> > > > > small for the sake of reuse and to keep APIs simple.
> > > 
> > > My understanding is that a library repo will have branches based
> > > on the version of go, so for example, it might have a branch
> > > called go-1 which will be where go get will look to find the
> > > latest version of the code that works with go-1.x.
> > > 
> > > > In this case we just have to require upstream to make releases
> > > > or publish either live ebuilds, or ebuilds versioned something
> > > > like 0_preYYYY-MM-DD.ebuild [1]
> > > 
> > > I don't think we are going to be able to require upstream to make
> > > releases, so that leaves us with:
> > >
> > > 1) using live ebuilds, which will never be allowed to have
> > > keywords by gentoo policy, or
> > > 2) publishing snapshots, which also means we have to create
> > > tarballs to match them. This will be a lot of work for us as
> > > maintainers. Also, the only way we will know when a new "version"
> > > of the library is released is to closely monitor the upstream git
> > > repository.
> > 
> > As I said in previous email, I think at least part of go community
> > sees this as an issue and this is something we can not solve right
> > now but rather need to work on this on case-by-case basis.
> > 
> > Some upstreams may be willing to do releases / follow semver.org or
> > something like that. But there will also be upstream which won't and
> > that's fine, we should be able to handle both cases.
> > 
> > Anyway, asking the upstream to do a release is simple enough and you
> > won't know until you ask.
> >  
> > > The other concern, which I believe zero was talking about is,
> > > once a library is installed in GOPATH, I don't think the go build
> > > system rebuilds it. In other words, "go get" will see that it is
> > > already there and I don't think it goes back out to the net to
> > > check for any changes.
> > 
> > I think when doing a `go build` it will check if newer version is
> > available and print a warning.
> >
> We may have to make some sort of utitilty to parse sources and check
> for updates, and roll tarballs to mirror.
> > 
> > > William
> > > 
> > 
> > 
> > 
> > --
> > Jan Matějka        | Gentoo Developer
> > https://gentoo.org | Gentoo Linux
> > GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B
> 
> 



---
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] dev-lang/go

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2499 bytes --]

On Sat, Feb 15, 2014 at 12:48:44AM +0100, yac wrote:
> On Fri, 14 Feb 2014 11:02:49 -0500
> Emery Hemingway <emery@vfemail.net> wrote:
> > The default GOROOT that go looks at for base libraries seems to be
> > compiled in so this should be pretty easy, like python but simplier.
> 
> I'm not sure what you are trying to solve here. Afaik GOROOT is used to
> determine where to install and it can be overriden from env.

Not overridden, but extended. See go help gopath.

> > An eclass could look at a GO_MINIMUM variable and install for each
> > version go that is present and matches.
> 
> It might be good idea to learn from others who'd been through this and
> I think the new python eclasses are good ones, going with something
> like PYTHON_TARGETS array (GOLANG_TARGETS ?)
 
 I would prefer go_targets if this becomes an issue, but it isn't at
 this point because there is only one target, go1, and we do not know if
 there will be a go2 or not.

> > Dropping old versions of go
> > will be easy because linking wont break, and new releases should be
> > forwards compatible.
> 
> So far yes I think but I guess that may be quite different with in the
> future with >1.x, and "should be" so there may be corner cases where the
> user does need to use earlier version.

Highly unlikely in the context of go1, and again, we don't know if there
is going to even be a go2 or not. The only reason there will be a go2 is
if there needs to be a change at the source level which can only be done
in a backward incompatible way.

The question really should be, do we want a system-wide workspace to
store third-party libraries [1]?
and if so, where do we put it -- maybe /usr/lib/go-gentoo should exist
along side /usr/lib/go?

The catch would be that every time you upgrade dev-lang/go, everything
stored in /usr/lib/go-gentoo has to be recompiled because there is no
guarantee that the libraries we have there are compatible with each
minor release of go1, only the source.

Then, the executables we have in /usr/bin will still run, but it would
be good to rebuild them as well to get the new libraries linked into
them.

If we had a work space in, say, /usr/lib/go-gentoo, we could leave the
executables in there and symlink them to /usr/bin. If we did that, it
would be easy for a user to rebuild everything in the workspace for the
new go by doing

emerge /usr/lib/go-gentoo/bin

Thoughts?

William

[1] http://golang.org/doc/code.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] dev-lang/go

[yac]

[-- Attachment #1: Type: text/plain, Size: 3440 bytes --]

On Sat, 15 Feb 2014 16:44:09 -0600
William Hubbs <williamh@gentoo.org> wrote:

> On Sat, Feb 15, 2014 at 12:48:44AM +0100, yac wrote:
> > On Fri, 14 Feb 2014 11:02:49 -0500
> > Emery Hemingway <emery@vfemail.net> wrote:
> > > The default GOROOT that go looks at for base libraries seems to be
> > > compiled in so this should be pretty easy, like python but
> > > simplier.
> > 
> > I'm not sure what you are trying to solve here. Afaik GOROOT is
> > used to determine where to install and it can be overriden from env.
> 
> Not overridden, but extended. See go help gopath.
> 
> > > An eclass could look at a GO_MINIMUM variable and install for each
> > > version go that is present and matches.
> > 
> > It might be good idea to learn from others who'd been through this
> > and I think the new python eclasses are good ones, going with
> > something like PYTHON_TARGETS array (GOLANG_TARGETS ?)
>  
>  I would prefer go_targets if this becomes an issue,

golang is more search friendly

> but it isn't at
>  this point because there is only one target, go1, and we do not know
> if there will be a go2 or not.

There still are different compilers at least, even if changing minor
version would be a non-issue. But I'm not familiar with those, I think
those are used for compiling for other than the supported archs (iirc
only x86 and x86_64)

> > > Dropping old versions of go
> > > will be easy because linking wont break, and new releases should
> > > be forwards compatible.
> > 
> > So far yes I think but I guess that may be quite different with in
> > the future with >1.x, and "should be" so there may be corner cases
> > where the user does need to use earlier version.
> 
> Highly unlikely in the context of go1, and again, we don't know if
> there is going to even be a go2 or not. The only reason there will be
> a go2 is if there needs to be a change at the source level which can
> only be done in a backward incompatible way.
> 
> The question really should be, do we want a system-wide workspace to
> store third-party libraries [1]?
> and if so, where do we put it -- maybe /usr/lib/go-gentoo should exist
> along side /usr/lib/go?

I assume you are talking about thirdparty packages installed by
portage, not by localy/manually by user. Well, without the system-wide
workspace to store the libraries, this whole go eclass would be kinda
pointless, no?

Currently /usr/lib/go/gentoo is used and I see no reason to change it.

> 
> The catch would be that every time you upgrade dev-lang/go, everything
> stored in /usr/lib/go-gentoo has to be recompiled because there is no
> guarantee that the libraries we have there are compatible with each
> minor release of go1, only the source.
> 
> Then, the executables we have in /usr/bin will still run, but it would
> be good to rebuild them as well to get the new libraries linked into
> them.
> 
> If we had a work space in, say, /usr/lib/go-gentoo, we could leave the
> executables in there and symlink them to /usr/bin. If we did that, it
> would be easy for a user to rebuild everything in the workspace for
> the new go by doing
> 
> emerge /usr/lib/go-gentoo/bin

Good idea.

> Thoughts?
> 
> William
> 
> [1] http://golang.org/doc/code.html



---
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] dev-lang/go

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 4549 bytes --]

On Wed, Feb 19, 2014 at 12:34:22PM +0100, yac wrote:
> On Sat, 15 Feb 2014 16:44:09 -0600
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > On Sat, Feb 15, 2014 at 12:48:44AM +0100, yac wrote:
> > > On Fri, 14 Feb 2014 11:02:49 -0500
> > > Emery Hemingway <emery@vfemail.net> wrote:
> > > > The default GOROOT that go looks at for base libraries seems to be
> > > > compiled in so this should be pretty easy, like python but
> > > > simplier.
> > > 
> > > I'm not sure what you are trying to solve here. Afaik GOROOT is
> > > used to determine where to install and it can be overriden from env.
> > 
> > Not overridden, but extended. See go help gopath.
> > 
> > > > An eclass could look at a GO_MINIMUM variable and install for each
> > > > version go that is present and matches.
> > > 
> > > It might be good idea to learn from others who'd been through this
> > > and I think the new python eclasses are good ones, going with
> > > something like PYTHON_TARGETS array (GOLANG_TARGETS ?)
> >  
> >  I would prefer go_targets if this becomes an issue,
> 
> golang is more search friendly
> 
> > but it isn't at
> >  this point because there is only one target, go1, and we do not know
> > if there will be a go2 or not.
> 
> There still are different compilers at least, even if changing minor
> version would be a non-issue. But I'm not familiar with those, I think
> those are used for compiling for other than the supported archs (iirc
> only x86 and x86_64)

Also add arm to the supported list along with amd64/x86-fbsd.

The only other compiler is gccgo [1], but it is part of the gcc
toolchain, so I have no idea what they are doing there, or if our
toolchain guys are even supporting it. Also, if you look at the comments
on that page, it is a bit behind dev-lang/go. It is not clear to me
either whether gccgo works on other architectures, and whether it is a
compiler or a front end like the old cfront used to be for c++. Also, I
don't know whether it will even share the same libraries as dev-lang/go;
it may just use standard libraries stored in /usr/lib.

In short, I have no clue how gccgo works. ;-)

> 
> > > > Dropping old versions of go
> > > > will be easy because linking wont break, and new releases should
> > > > be forwards compatible.
> > > 
> > > So far yes I think but I guess that may be quite different with in
> > > the future with >1.x, and "should be" so there may be corner cases
> > > where the user does need to use earlier version.
> > 
> > Highly unlikely in the context of go1, and again, we don't know if
> > there is going to even be a go2 or not. The only reason there will be
> > a go2 is if there needs to be a change at the source level which can
> > only be done in a backward incompatible way.
> > 
> > The question really should be, do we want a system-wide workspace to
> > store third-party libraries [1]?
> > and if so, where do we put it -- maybe /usr/lib/go-gentoo should exist
> > along side /usr/lib/go?
> 
> I assume you are talking about thirdparty packages installed by
> portage, not by localy/manually by user. Well, without the system-wide
> workspace to store the libraries, this whole go eclass would be kinda
> pointless, no?
> 
> Currently /usr/lib/go/gentoo is used and I see no reason to change it.

Well, I was suggesting go-gentoo to keep third party libraries out of
the standard go tree and based on the definition of a workspace from the
go documentation.


> > The catch would be that every time you upgrade dev-lang/go, everything
> > stored in /usr/lib/go-gentoo has to be recompiled because there is no
> > guarantee that the libraries we have there are compatible with each
> > minor release of go1, only the source.
> > 
> > Then, the executables we have in /usr/bin will still run, but it would
> > be good to rebuild them as well to get the new libraries linked into
> > them.
> > 
> > If we had a work space in, say, /usr/lib/go-gentoo, we could leave the
> > executables in there and symlink them to /usr/bin. If we did that, it
> > would be easy for a user to rebuild everything in the workspace for
> > the new go by doing
> > 
> > emerge /usr/lib/go-gentoo/bin
> 
> Good idea.
> 
> > Thoughts?
> > 
> > William
> > 
> > [1] http://golang.org/doc/code.html
> 
> 
> 
> ---
> Jan Matějka        | Gentoo Developer
> https://gentoo.org | Gentoo Linux
> GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B


[1] http://golang.org/doc/install/gccgo

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]