On 18/03/10 at 10:31 +0900, Eric H. wrote:
Unfortunately I end up having to handle most of the issues that Debian
for what seems to boil down to policy reasons (Neil W.'s work in
Are you aware of the tone you use in this discussion? “issues that
Debian creates” kind-of implies that we create issues on purpose.
“reject for what seems to boil down to policy reasons” implies that you
consider that what our policy might be should probably be ignored if it
fixed your problem.
We certainly can’t cooperate when you don’t bother to raise any issues
in the places we’re looking for them.
There was attempts (by me and others) to try to improve the situation.
Given how the rubygems tend to see the problem, I’ve given up, because
it’s better for my mental health not to engage into discussions with
poisonous people that kill all the fun.
Not taking advantage of rubygems/defaults/operating_system is
especially odd to me as it would allow upgrades of RubyGems to
continue to work while maintaining Debian’s customizations. Last I
checked the only changes made to RubyGems by Debian could be
encapsulated in this one file.
When did you last check? You didn’t know about ruby-full/ruby1.9.1-full,
so I assume that must have been a long time ago.
Maybe you get so much sarcasm and nasty comments because people are
genuinely frustrated with what Debian provides by default. Maybe
installing ruby-full by default instead of the minimal ruby will
reduce your frustrations.
Well, people are also frustrated the other way around, because they are
required by some ruby developers to use rubygems instead of apt-get,
which they can use for all other scripting languages out there.
Oftentimes people are following instructions they found on the web
that were written for non-Debian/Ubuntu. On OS X, BSD, and most other
Linux versions those instructions will work without modification, but
since Debian is subtly different they end up coming here and we end up
answering the same questions over and over, which will inevitably lead
to us making sarcastic, nasty comments.
From maintaining RubyGems I’ve learned that maintaining a large,
popular open-source library requires a thick skin and the ability to
say “yeah, what I’m doing is not what people want” sometimes.
I actually think that the Rubygems situation in Debian is “OK”. I don’t
see how changing the way the packages are split would improve the
situation. Could you point to specific problems that people have? I’m
aware of two problems:
- the location of installed gems in Debian (in /var instead of /usr),
but that is dictated by policy. I personally would have preferred to
follow what rubygems does, but I was not directly in charge of that
- the fact that, when you try to install a gem, you might need to
install some other packages that are required to build that specific
gem (packages containing header files, compiler, etc). What is
currently done is that installing rubygems suggests (in the package
manager sense) to install the ruby header files, and a
“build-essential” package that depends on gcc, g++, etc. I can’t see
what else we could do, given that:
- some people might want to install only pure-ruby gems, so requiring
them to install a compiler and header files when installing rubygems
would be annoying.
- we can’t guess in advance which other header files will be needed by
the user (= the user installs rubygems just to install the
“ruby-foo” gem, that requires the headers for “libfoo” to be
We provide tools in Debian that allow the user to know
which package contains a specific file. Of course we can’t just
require the installation of all the packages containing header
files in Debian.
Are you aware of other issues?
Note that our position is rather accurately described in
We currently don’t have any real problem with rubygems itself. Most of
our problems are caused by gem developers (those developing libraries,
not those developing rubygems itself) that ship libraries as .gem only
(so we need to repackage the source as a .tgz), or that ship code that
uses “require ‘rubygems’”, that we have to patch out before installing
with setup.rb. However, that recommended practice is changing slowing in
the good direction, which is great.