Re: Go (golang) packaging, part 2
* Wouter Verhelst:
> 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.
I think that "Consistency across multiple platforms" can be a useful
argument. But if either upstream's or the distribution's view of How
Things Ought To Work are ignored for the sake of consistency, something
has gone wrong. (Which is my impression of what happened with Ruby.)
> 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: [...]
On the other hand it gives users the power to get things done, without
having to care how they can build "proper" distro packages.
People expect upstream's "get software" command to Just Work, just as
they expect "./configure && make && sudo make install" or "perl
Makefile.PL && make && make test && sudo make install" to Just Work. In
my experience autoconf and perl-based build systems usually don't write
all over the parts of the system that dpkg is responsible for -- they
put their stuff into /usr/local and I can even override that using
documented environment variables or command line parameters.
This is exactly the kind of behavior I would expect when running "go
install" on a Debian system. It should be useful as intended by its
authors but leave certain parts of the system alone that are off-limits