Re: Go (golang) packaging, part 2
On Tue, Jan 29, 2013 at 08:25:38AM +0100, Michael Stapelberg wrote:
> Hi Hilko,
> Hilko Bengen <firstname.lastname@example.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.
Copyshops should do vouchers. So that next time some bureaucracy requires you
to mail a form in triplicate, you can mail it just once, add a voucher, and
save on postage.