On 27/08/13 15:57 -0400, Matthew Miller wrote: There was a good start to this conversation had at Flock a couple of weeks ago. Thankfully other distributions have put a lot of thought into this as well, but there are a number of things that I feel we can handle in a very developer/user enabling way. Libraries of golang are basically src only, but having the *.a available are very nice. The thing that I've been grappling with lately, is that the *.a are not arch dependent. Due to the way the golang compiler works, any host can compile for any end target. So by setting GOROOT to be in %{_libdir}, it is causing an arbitrary BuildArch enforcement. _only_ for executables, is the final build arch specific. (e.g. if you set GOOS="windows" GOARCH="386" you can compile a *.exe, even if you can not execute it on the host that compiled it) So I've been working with Adam Goode and Adam Miller on a more flexible layout that would have libraries be noarch, and have sub packages for the various ARCHs *.a files, so you could pull in only the ones needed for a final binary executable. There is a bit of work needed, and I'm excited to work on it, while balancing my other work. For a recent tool, I packaged up a single library, that could be a current example of getting libraries packaged, but not where I want to get to. First a non-arch dependent way to handle the $GOROOT/pkg and $GOROOT/src agoode had tried symlinks, but some "magic" in the build had caused a broken install, so he reverted that. The final binaries are static (Not different than haskell or ocaml), unless something uses 'cgo' which causes the resulting binary to have dynamic links to only that library. As for gccgo, it does compile to dynamic, but the GOROOT and GOPATH are not respected, so it's currently an exercise of the user to get their -I<path> flags setup for the imports of their project. Take care, vb

On 28/08/13 17:07 -0400, Matthew Miller wrote: golang libraries are basically -devel packages, not just subpackages. The part that is going to need revision is how to handle that fact that any given library, should provide subpackages for all the arch's of *.a, that can be installed individually or exist together. Further, I have tasks to work putting the packaging guideline documentation on the fedora site. The Flock workshop was good, though was mostly abstract discussion, not substantive work on the documentation. as for examples: * import "launchpad.net/goyaml" - https://brewweb.devel.redhat.com/packageinfo?packageID=43627 * go-cdnauth an internal tool, that has imports as well - https://brewweb.devel.redhat.com/packageinfo?packageID=43625 Take care, vb

On Thu, Aug 29, 2013 at 12:12:02PM -0400, Vincent Batts wrote: I'm beginning to _strongly_ believe that we should follow the debian idea here: https://wiki.debian.org/MichaelStapelberg/GoPackaging and not package pre-compiled Go libraries at all (outside of the standard library). Developers _not_ making RPMs are encouraged to ignore these packages and do everything the 'go get' way, whereas RPMs would all set GOPATH to "/usr/share/gocode" and use that. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org&gt;

On Sun, Sep 22, 2013 at 12:07:20AM -0400, Matthew Miller wrote: Update -- "official" debian guidelines are at: http://pkg-go.alioth.debian.org/packaging.html (based on the previous link above but more fleshed-out). -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org&gt;

On 23/09/13 11:01 -0400, Matthew Miller wrote: Awesome. I'll jump on there with you. There's been a lot of work happening to get this ironed out. Hopefully guidelines will just fall out. This is where the golang developers left this as an exercise of the distribution packagers. :-)

On Mon, 23 Sep 2013 16:43:19 -0400 Vincent Batts <vbatts(a)redhat.com&gt; wrote: and what about the go compiler in the GCC? Its advantage is broader architecture support than golang which is x86/x86_64/arm only. Dan

On 23/09/13 22:53 +0200, Dan Horák wrote: This is something still pretty fuzzy. Anything to compile with gccgo could use this same idiom, and just add the -I/usr/share/gocode/src flags as needed. While gccgo would let folks attempt compiles on mips and others that the golang compiler does not reach yet, this is considered an exercise of developers. While we're at reaching multiple arches, the golang compiler itself can compile windows, osx and bsd binaries from the 'golang' rpm in fedora. But I'm not sure that need be fully accommodated, since it would likely be an edge case for a developer. As long as binaries for linux i686, x86_64 and arm are capable. Right? Take care, vb