From: yac <yac@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] dev-lang/go
Date: Tue, 11 Feb 2014 01:38:44 +0100 [thread overview]
Message-ID: <20140211013844.4057ddb2@gentoo.org> (raw)
In-Reply-To: <20131230154817.34a69433@ciguri>
[-- 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 --]
next prev parent reply other threads:[~2014-02-11 0:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-30 20:48 [gentoo-dev] dev-lang/go Emery Hemingway
2013-12-30 21:20 ` Rick "Zero_Chaos" Farina
2013-12-31 2:16 ` [gentoo-dev] dev-lang/go Ryan Hill
2014-01-01 6:51 ` [gentoo-dev] dev-lang/go Alec Warner
2014-02-11 0:38 ` yac [this message]
2014-02-13 14:20 ` Emery Hemingway
2014-02-13 17:59 ` William Hubbs
2014-02-13 22:36 ` Emery Hemingway
2014-02-14 12:30 ` Jan Matejka
2014-02-14 16:02 ` Emery Hemingway
2014-02-14 23:13 ` William Hubbs
2014-02-15 16:06 ` Emery Hemingway
2014-02-14 23:48 ` yac
2014-02-15 22:44 ` William Hubbs
2014-02-19 11:34 ` yac
2014-02-20 0:52 ` William Hubbs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140211013844.4057ddb2@gentoo.org \
--to=yac@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox