Re: Go (golang) packaging, part 2
Hi Hilko,
Hilko Bengen <bengen@debian.org> writes:
> This is a pity for those of us who don't really subscribe to "get
> everything from github as needed" model of distributing software.
Yes, but at the same time, it makes Go much more consistent across
multiple platforms. We should tackle one issue at a time. I suppose in
the future, upstream’s take on library distribution might change. For
now I agree with upstream on this — not introducing another source of
errors/mistakes for the end user (version problems involving not only go
get, but also a Debian version of some library) seems like a good idea.
>> Go library Debian packages such as golang-codesearch-dev will ship the
>> full source code (required) in /usr/lib/gocode plus statically
>> compiled object files (not required, but no downsides) compiled with
>> gc from the golang-go Debian package.
>
> Since one of the stated goals of the Go language and also the golang
> compiler are fast builds: How about using the Emacs / Common-Lisp /
> Python approach: Ship only source files in the .deb packages and build
> object files during post-install?
What advantage would that have? It won’t change the fact that we will
only distribute Go libraries for building Debian binary packages.
> How does gccgo fit into this picture, apart from the problem that object
> files generated using gccgo are not compatible with those generated
> using golang-go?
I tried to explain that one cannot use gccgo to create dynamically
linked shared libraries from Go libraries. At least not at the
moment. All it can do is dynamically linked executables.
--
Best regards,
Michael
Reply to: