On 11/09/10 at 14:15 +0900, Austin Ziegler wrote:
> On Fri, Sep 10, 2010 at 1:54 AM, Lucas Nussbaum
> <lucas / lucas-nussbaum.net> wrote:
> > On 10/09/10 at 02:41 +0900, Aaron Patterson wrote:
> >> I think this kind of problem already happens today with Debian. ?IIRC,
> >> doing a normal install of Ruby on debian doesn't provide openssl, you
> >> have to specifically ask for it.
> > This was true in the past, but is no longer the case.
> >
> > Please avoid spreading FUD about Ruby and Debian. It just makes our work
> > less fun than it should be.
> 
> Lucas:
> 
> I just dealt with a rather painful problem on Ubuntu 10.04 because of
> the changes that Debian made to RubyGems, a need to upgrade to
> RubyGems 1.3.7 (there are gems that will not install unless you're on
> at least that version of RubyGems), and my own belief that the
> Debian/Ubuntu situation wasn't as bad as it used to be (given that I
> can do "gem update --system" on Mac OS without breaking anything, and
> what others have said). A small dose of my own idiocy in pushing
> forward despite how things looked didn't help.
> 
> When I did "apt-get install ruby1.8", I didn't get rdoc1.8,
> rubygems1.8, ri1.8, or libopenssl-ruby1.8, all of which I consider
> standard parts of the Ruby ecosystem.

Ubuntu update policy for stable releases is rather strict, and it is not
possible to backport major changes to them. It is possible that the
merge of rdoc1.8 and libopenssl-ruby1.8 happened in a version later than
the one in Ubuntu 10.04 (my main focus is on Debian ; I don't have
enough time to follow closely how Ubuntu synchronizes with Debian).
Anyway, the change will be in 10.10.

For rubygems1.8, I don't see how you could expect to have it installed
by default when you apt-get install ruby1.8. It is not shipped with Ruby
1.8, so it would be a pretty strange decision on the Debian side to
include it by default. In the upcoming Ruby 1.9.2 packages, we respect
the upstream developers' choice to include it by default (despite not
being happy with it, and not being happy that the seperately-shipped
rubygems is incompatible with the 1.9.2 rubygems), and gem1.9.1
(1.9.1 = ruby compat version, not necessarily ruby version ; ruby
version = 1.9.2 in Debian currently) is available.

Regarding the problem that led you to having to:
> Things were badly broken enough that I had to go through a whole
> series of "dpkg --remove --force-dependencies" and equivalent --purge
> calls just to be able to reliably reinstall enough Ruby to use rvm for
> the future to avoid this.

It would be great if you could submit a proper bug report (a transcript
of a shell session, starting from scratch, for example). I am not aware
of any issue that would lead to that.

> Things are much better than they were three or four years ago, but the
> unfortunate reality is that what Aaron said isn't FUD; I just
> experienced it in the last 36 hours.
> 
> Aside from what I consider to be the unforgivable breakage to
> rubygems, the Debian maintainers are doing a much better job of
> handling Ruby than has been done in the past and than has been done in
> other situations. However, I still don't think that it's quite enough
> (in part because of the unforgivable breakage to rubygems).

You might be happy (or not) to learn that I just committed a change that
enables gem update --system _if_ the user exports a specific environment
variable, after displaying a disclaimer. I'm not sure if that's the
"unforgivable breakage to rubygems" you are talking about.

Now, I don't think that "unforgivable" is an appropriate term to use in
a technical discussion. I am personally doing Ruby maintenance on a
volunteer basis, and I get a lot of shit from that (including many from
you in the past).
Sure, not everything is perfect, but we are working towards improving
the situation. Each time I read people writing about "unforgivable
breakages", it makes me want to stop doing Ruby maintenance in Debian.
(It's actually very likely that I will stop doing Ruby work after Debian
6.0 is released).

- Lucas