Comment 11 for bug 228345

2008/5/27 Lucas Nussbaum <email address hidden>:
> I'd prefer if it went upstream, if applicable.

I feel it is a packaging problem. Gem will not need altering. I've
subscribed you to the bug and I'd appreciate your thoughts over there.

> I'm not sure you understand the rationale for splitting ruby1.9.

So that other packages don't pull in stuff they don't need and reduce
the perennial dependency problem. However those packages are a
minority application. The majority want ruby1.x to include gems, to
provide an executable called 'ruby', and supply all the subsiduary
tools and they will be (and indeed are) confused if that isn't the
case.

> It already exists, it's called ruby-full:
> Package: ruby-full
> [..]
> Depends: irb, libdbm-ruby, libgdbm-ruby, libopenssl-ruby, libreadline-ruby, rdoc, ri, ruby, ruby1.8-dev
> Recommends: libtcltk-ruby, ruby-elisp
>
> But currently, it pulls ruby1.8, since that's the default version, not
> ruby1.9.

Yes, but that's the problem - one of marketing. Names matter. People
expect ruby1.x to provide what they need to use ruby. They don't
expect it to be just core ruby. If packagers need smaller packages
then they should be the one handling the 'what is the package called'
problem, not the poor end user who just wants to develop in ruby.

For me ruby1.x should be user facing, pull in everything required to
develop in ruby (including gems which is notably missing from your
list above). We should have ruby1.x-core for those packagers who need
the lighter less fattening alternative (with ruby1.x-core handling the
'alternatives' system properly and providing the 'ruby' symlink).

The 'ruby' package needs to be a virtual that pulls the 'current'
version, but is satisfied by all the other options (which will include
jruby and rubinus before too long).

So it is really just a package renaming issue, which is a bit of a
pain in the backside, but it will improve the standing of
Debian/Ubuntu ruby in the community enormously if it is done. And it
sets us up to handle the various interpreter combinations going
forward.

--
Neil Wilson