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
next…
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