Re: [RFC] Go (golang) packaging

[Guillem Jover <guillem@debian.org>]

On Wed, 2013-01-02 at 09:15:59 +0100, Michael Stapelberg wrote:
> Shawn <shawnlandden@gmail.com> writes:
> > Henceforth when a go program depends on a go library, those go
> > libraries are ALWAYS compiled in statically. Static linking causes
> > many problems for distributions like Debian, and therefore this

> Can you please tell us which specific problems are caused by static
> linking for Debian? I’m not aware of any.

Well, that's surprising, I would have thought this has been discussed
at lenght in the past, in any case here are several reasons (I'm most
probably forgetting others):

  * Changes in libraries might require recompiling all of their rdeps.
    This includes:
    - Bug fixes (security or otherwise, as pointed out in the thread).
    - Performance improvements.
    - Private dependencies, as they leak to rdeps. When a library uses
      another library privately this dependency gets linked in directly
      in all other rdeps, when that library stop depending on that
      private dependency, all rdeps need to be rebuilt.
  * We might need to keep the sources for all library instances that
    have been linked into any other package, to comply with license
    conditions (see the Built-Using comment on this thread too).
  * Larger dependency chains. Because private libraries need to be
    pulled in even by indirect dependencies, the sources and static
    libraries need to be available at compile time, this means the
    libfoo-dev dependencies and Build-Depends chains are going to
    be larger.
  * Produces huge binaries (and packages), which use more memory that
    cannot be shared across processes (unlike shared libraries).

The first point alone, make such things a PITA to manage in a
distribution, and are a waste of buildd and people's time who need
to coordinate those things. The rest imply a waste of resources or
added complexity which could be avoided.

> I’m somewhat hesitant to say “Let’s just use gccgo in Debian” because
> static linking is one of the advantages of Go (IMO, but also a shared
> feeling by the community I think) and the gc compiler is fast, which is
> another advertised advantage.

While it's true that static linking can produce varying degrees of faster
binaries depending on the conditions (architecture, amount of libraries,
etc), I don't think it's worth the tradeoff for the general case and I'm
having a hard time seeing a new compiled system language that does not
support shared libraries as a serious contender.

Thanks,
Guillem