(Re-adding 588...@bugs.debian.org in Cc, I hope you didn't strongly mean to send this as a private mail.)
On 25/08/10 at 22:07 +0200, Clive Crous wrote: > On 25 August 2010 21:41, Lucas Nussbaum <lu...@lucas-nussbaum.net> wrote: > > I understand that it's inconvenient, but maybe you could help > > investigate the issue and propose a solution? > > I've looked into this from my end and, to be frank, the dual rubygems > (as a package and within the 1.9 series) is just too much of a mess. > If it were up to me I'd just say kill off the extra package and > install it with ruby itself since that's where it's been included > upsteam, but that's already been dismissed by someone else in this > report last month. The problem is we have to ship Rubygems 1.3.7 for Ruby 1.8, and we would rather avoid a lot of code duplication between the Rubygems from 1.3.7 and the Rubygems from Ruby 1.9.2 stdlib. At least we have that fallback solution... But I hope that we don't have to use it. > Someone with more understanding of debian's package philosophy needs > to make a call here. Ideally 1.9.2 (imo) should never have been pushed > past and through into testing since ruby without gems is like c > without libraries ... yea sure you can use it - but it's almost > pointless. It's not clear yet whether it's a Rubygems bug or a Ruby bug yet. Ruby 1.9.2 introduced some regressions (like the ones due to the removal of '.' from load path). But we had no choice, since Ruby 1.9.1 is unsupported by the ruby developers and doesn't even build on i386 anymore. (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580852) Lucas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
