Re: Go (golang) packaging, part 2

[Iustin Pop <iustin@debian.org>]

On Tue, Jan 29, 2013 at 09:44:43AM +0100, Wouter Verhelst wrote:
> On Tue, Jan 29, 2013 at 08:25:38AM +0100, Michael Stapelberg wrote:
> > 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.
> 
> "consistency across multiple platforms" has been claimed as a benefit
> for allowing "gem update --system" to replace half of the ruby binary
> package, amongst other things. It wasn't a good argument then, and it
> isn't a good argument now.
> 
> > 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.
> 
> The problem with having a language-specific "get software" command is
> that it introduces yet another way to get at software. There are many
> reasons why that's a bad idea, including, but not limited to:
> - most config management systems support standard packages, but not
>   language-specific "get software" commands, making maintenance of
>   multiple systems with config management harder if there aren't
>   any distribution packages for the things you want/need to have.
> - It's yet another command to learn for a sysadmin.
> - It makes it harder for the go program to declare a dependency on
>   non-go software, or vice versa
> 
> So there are real and significant benefits to be had by actually trying
> to do this right, meaning, "this will have to do" (as opposed to "this
> will have to do /for now/, but we'll tackle doing it better once this
> bit works right") would be a pity.

I would add one thing here: Haskell/GHC also (currently) doesn't create
shared libraries, and instead builds the program statically, but the
Debian Haskell group still tries to package as best as they can the
development libraries, for all the reasons above (which are very good
reasons, IMHO).

So, take this as an example of another language which doesn't do shared
linking but for which libraries are still packaged in Debian.

regards,
iustin