On 18/03/10 at 10:31 +0900, Eric Hodel wrote:
> On Mar 17, 2010, at 14:32, Lucas Nussbaum wrote:
> 
> > I hope this clarifies the status of Ruby in Debian and Ubuntu a bit.
> > Also, it would be great if all the sarcasm and nasty comments on
> > this list each time someone brings up Ruby and Debian or Ubuntu
> > could be reduced a bit. I am working on providing Ruby packages in
> > Debian and Ubuntu as a volunteer, and don't really enjoy all the
> > flames I get on this list. Constructive criticism is welcomed
> > (preferably as bug reports), but is very rare here, unfortunately.
> 
> Unfortunately I end up having to handle most of the issues that Debian
> creates due to their splitting up Ruby into multiple packages because
> of the way it affects Ruby and RubyGems.  I can reduce my support load
> and increase my free time by saying "install all of Ruby and RubyGems
> by hand on Debian and Ubuntu".  Once RubyGems is installed it's fairly
> smooth sailing on Debian unless you install a gem that needs to
> compile against missing headers.
> 
> It's especially frustrating when features are added to RubyGems that
> have the express goal of helping Debian and Ubuntu are either ignored
> (rubygems/defaults/operating_system, added in 1.2.0) or are rejected
> for what seems to boil down to policy reasons (Neil Wilson's work in
> http://bugs.debian.org/403407).

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.

> When you say things like:
> 
> > The problem is that the upstream rubygems developers don't care, and
> > that it's impossible to change that without their cooperation.
> 
> I don't see how we (that work on RubyGems) could possibly have ever
> cared if you're not subscribed to the mailing list where you would
> raise those concerns nor have you filed any bugs with any of these
> concerns.
> 
> 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
  decision.
- 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 installed).
    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
http://pkg-ruby-extras.alioth.debian.org/rubygems.html

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.
-- 
| Lucas Nussbaum
| lucas / lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas / nussbaum.fr             GPG: 1024D/023B3F4F |