[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Go (golang) packaging, part 2

On 30/01/2013 05:57, Michael Stapelberg wrote:
> 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?

I'm not very familiar with the situation myself, but the gist of it, as I
understand, is that Ruby upstream wants everything to be installed via RubyGems,
while we want everything to be installed via dpkg. I think there was some issue
regarding which paths can be controlled by which package manager.

> 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™.

Having multiple package managers which don't know about each other on a system
is evil™ (but in some cases, can be managed properly).

The issue here is that:
 1. If software that depends on native packages is installed using "go get"
    or whatever other language-specific package manager, e.g. pip for Python or
    gem for Ruby is installed, there is no way to declare a dependency on
    those. For example, the Python mysql bindings require some MySQL C headers
    which are available in Apt, but you won't know until your pip install run
    fails due to missing headers. After you're done, you move on to your next
    dependency which also fails due to missing headers, and the next, and the

 2. If something installed from your language-specific package manager is in a
    path that a Debian package overrides, dpkg is going to barf because it
    doesn't know where those files come from. This of course applies to
    randomly ./configure-ing stuff with --prefix=/usr and running make install.

 3. Software packages from Apt cannot declare dependencies against
    language-specific packages, for the same reasons highlighted in #1.

Now, some cases where these problems are (partially) mitigated is when
installing using the upstream package manager into a language-specific sandboxed
environment, e.g. python-virtualenv. I say partially because this doesn't solve
the issue in #1. In fact, my example there was something I ran into while
running a pip install inside a virtualenv.

> I have no interest in actively working against upstream’s
> recommendations and against my own beliefs. Not now, not in the future.

Upstreams should always be OS/distro-agnostic wherever possible, so the language
specific package manager will always be the recommendation, even if it isn't the
best solution.

Kind regards,
Loong Jin

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: