Re: Go (golang) packaging, part 2
Wouter Verhelst <firstname.lastname@example.org> writes:
> "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 am not familiar with the Ruby situation, I only know that many Ruby
developers seem to be very angry at Debian people. Is there a summary of
the events that I could read?
> - 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.
“most config management systems” should be fixed, then. If you mean
systems like puppet with that statement, I don’t see a reason why you
would _ever_ want to obtain a Go library with puppet. When deploying Go
software, you either a) compile it on your development machine, then
distribute it (no libraries needed) or b) install the Debian package
(libraries will be available, as explained in previous emails).
> - It's yet another command to learn for a sysadmin.
Sysadmins are not developers and therefore don’t need to learn any new
> - It makes it harder for the go program to declare a dependency on
> non-go software, or vice versa
Dependency as in Debian package dependency? In that case I really don’t
understand what argument you are trying to make here.
Overall, I am not convinced that using “go get” on Debian is evil™.
> 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 have no interest in actively working against upstream’s
recommendations and against my own beliefs. Not now, not in the future.