Re: Go (golang) packaging, part 2
- To: firstname.lastname@example.org
- Subject: Re: Go (golang) packaging, part 2
- From: Jon Dowland <email@example.com>
- Date: Fri, 1 Feb 2013 10:00:32 +0000
- Message-id: <[🔎] 20130201100032.GA12622@debian>
- Mail-followup-to: firstname.lastname@example.org
- In-reply-to: <20130130234635.GA1777@csclub.uwaterloo.ca>
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <20130129084443.GB24411@grep.be> <firstname.lastname@example.org> <email@example.com> <CAKTje6GJ9WO5gDV_exc5Y7B-D_KBdsE+bfGiYFXj66j-uNKQag@mail.gmail.com> <loom.20130130T221150firstname.lastname@example.org> <20130130234635.GA1777@csclub.uwaterloo.ca>
On Wed, Jan 30, 2013 at 06:46:35PM -0500, Lennart Sorensen wrote:
> Absolutely. As a user I have a nice package management system that I
> know how to use and which works well. I don't need another one.
As a Haskell developer, I find cabal much more convenient than nothing,
in the situation where the library I want is not packaged by Debian yet.
If I want my haskell libraries and programs to reach a wide audience, I
need to learn Cabal anyway.
> It is not the job of a language developer to invent yet another bloody
> package distribution and installation system.
And yet they do, and so we need to manage it.
Remember that Debian does not just provide a package management system: it also
provides repositories and dictates what goes in them according to the DFSG.
Whilst adding new repositories is relatively simple for users (and growing in
popularity for upstreams), installing bare .deb files is still not a very
smooth process (although massively improved by e.g. gdebi these days)
From an upstream POV, they want their software in the hands of end users. They
don't want to have to learn and build a myriad of different package types
(.deb, .rpm, etc.) and crucially neither do we. In many cases they don't want
to have to wait for a distro to package their software for them either.
In the Go case, their users are people who might have a shell/web account but
not admin access on a shared host somewhere, running god knows what distro and
version, hence having a self-contained fat binary that is guaranteed to run
wherever libc is meets their goals.