I've been asked to help package / review a project written in Go. Since the language is new, we don't have packaging guidelines (unless I've missed them!), and I'm a Go newbie myself, so I'm left with some questions.
The first question I have is over the location of packages -- the library modules. The ones that are part of golang are under %{_libdir}/golang/src/pkg. Should third-party packages go alongside, or % elsewhere?
Also it appears that Go programs compiled with the canonical golang are statically linked (http://golang.org/doc/faq#Why_is_my_trivial_program_such_a_large_binary). Gccgo supports dynamic linking, but I'm not sure about compatibility issues.
On 27/08/13 15:57 -0400, Matthew Miller wrote:
I've been asked to help package / review a project written in Go. Since the language is new, we don't have packaging guidelines (unless I've missed them!), and I'm a Go newbie myself, so I'm left with some questions.
The first question I have is over the location of packages -- the library modules. The ones that are part of golang are under %{_libdir}/golang/src/pkg. Should third-party packages go alongside, or % elsewhere?
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.
Also it appears that Go programs compiled with the canonical golang are statically linked (http://golang.org/doc/faq#Why_is_my_trivial_program_such_a_large_binary). Gccgo supports dynamic linking, but I'm not sure about compatibility issues.
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 Wed, Aug 28, 2013 at 03:27:34PM -0400, Vincent Batts wrote:
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.
So, is that example what we should follow if we have some libraries we'd like to package up now? (Should these basically only generate -devel subpackages?) Is it okay to review it copying your basic idea now but with the caveat that we'll update if we get closer to what you want to get to?
On 28/08/13 17:07 -0400, Matthew Miller wrote:
On Wed, Aug 28, 2013 at 03:27:34PM -0400, Vincent Batts wrote:
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.
So, is that example what we should follow if we have some libraries we'd like to package up now? (Should these basically only generate -devel subpackages?) Is it okay to review it copying your basic idea now but with the caveat that we'll update if we get closer to what you want to get to?
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:
So, is that example what we should follow if we have some libraries we'd like to package up now? (Should these basically only generate -devel subpackages?) Is it okay to review it copying your basic idea now but with the caveat that we'll update if we get closer to what you want to get to?
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.
It looks like the Haskell guidelines address this by making the packages not produce -devel subpackages but instead have a provides line like this:
Provides: golang-%{pkg_name}-devel = %{version}-%{release}
On Thu, Aug 29, 2013 at 12:12:02PM -0400, Vincent Batts 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.
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.
On Sun, Sep 22, 2013 at 12:07:20AM -0400, Matthew Miller 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).
To back this up:
* Building the static libraries doesn't really buy anything other than faster build times, and it's not like the Go compiler is really slow.
* The static .a files are _very_ specific to Go compiler version -- objects built with Go 1.1.1 will not work with Go 1.1.2. This means that all golang-*-devel packges would need to be rebuilt when Go has even a minor update.
* Putting the .a and source files into the system GOROOT means that they're found when _rebuilding_ the same package, and the previous spec file conditional to detect and work around this wasn't working right.
* In absence of a strong reason to do things differently, it'd be nice to be consistent with Debian.
On Sun, Sep 22, 2013 at 12:07:20AM -0400, Matthew Miller 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).
Update -- "official" debian guidelines are at:
http://pkg-go.alioth.debian.org/packaging.html
(based on the previous link above but more fleshed-out).
On Sun, Sep 22, 2013 at 02:34:24PM -0400, Matthew Miller 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).
Update -- "official" debian guidelines are at: http://pkg-go.alioth.debian.org/packaging.html
I didn't find an existing Fedora packaging draft, so I started one at
https://fedoraproject.org/wiki/PackagingDrafts/Go
this is very much a skeleton and needs help. But hopefully this will get it started.
On 23/09/13 11:01 -0400, Matthew Miller wrote:
I didn't find an existing Fedora packaging draft, so I started one at
https://fedoraproject.org/wiki/PackagingDrafts/Go
this is very much a skeleton and needs help. But hopefully this will get it started.
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 22/09/13 14:34 -0400, Matthew Miller wrote:
On Sun, Sep 22, 2013 at 12:07:20AM -0400, Matthew Miller 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).
Update -- "official" debian guidelines are at:
http://pkg-go.alioth.debian.org/packaging.html
(based on the previous link above but more fleshed-out).
so here is something else to vet out, like the work done for the ruby RPMS. Since there is support API versioning for the go language, how best to accommodate that in the requires/provides? Currently the language spec is 'go1', so everything in the 1.x version _will_ comply to this spec. Eventually they'll have a go2, etc.
Should the 'golang' package have a: Provides: golang(release) = 'go1' The binaries would have a BuildRequires and libraries would Require, to match the API version?
Take care, vb
On Mon, 23 Sep 2013 16:43:19 -0400 Vincent Batts vbatts@redhat.com wrote:
On 22/09/13 14:34 -0400, Matthew Miller wrote:
On Sun, Sep 22, 2013 at 12:07:20AM -0400, Matthew Miller 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).
Update -- "official" debian guidelines are at:
http://pkg-go.alioth.debian.org/packaging.html
(based on the previous link above but more fleshed-out).
so here is something else to vet out, like the work done for the ruby RPMS. Since there is support API versioning for the go language, how best to accommodate that in the requires/provides? Currently the language spec is 'go1', so everything in the 1.x version _will_ comply to this spec. Eventually they'll have a go2, etc.
Should the 'golang' package have a: Provides: golang(release) = 'go1'
The binaries would have a BuildRequires and libraries would Require, to match the API version?
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 Mon, Sep 23, 2013 at 10:53:26PM +0200, Dan Horák 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.
I think the general consensus is that until the language matures we prefer to use the reference compiler.
On 23/09/13 22:53 +0200, Dan Horák wrote:
On Mon, 23 Sep 2013 16:43:19 -0400 Vincent Batts vbatts@redhat.com wrote:
so here is something else to vet out, like the work done for the ruby RPMS. Since there is support API versioning for the go language, how best to accommodate that in the requires/provides? Currently the language spec is 'go1', so everything in the 1.x version _will_ comply to this spec. Eventually they'll have a go2, etc.
Should the 'golang' package have a: Provides: golang(release) = 'go1'
The binaries would have a BuildRequires and libraries would Require, to match the API version?
and what about the go compiler in the GCC? Its advantage is broader architecture support than golang which is x86/x86_64/arm only.
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
packaging@lists.fedoraproject.org
-
Dan Horák -
Matthew Miller -
Vincent Batts