[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: New interpreter packages available for testing



On 07/03/11 at 13:00 -0300, Antonio Terceiro wrote:
> Antono Vasiljev escreveu isso aí:
> > On Sun, 2011-03-06 at 10:04 +0100, Lucas Nussbaum wrote:
> > > Note that we have two alternatives trees (one for ruby, one for gem). It's not
> > > convenient to have a single one with alternatives. I think that it would make
> > > sense to have a separate "ruby-switcher" tool, that would:
> > > - change all alternatives at the same time
> > > - ensure that needed native packages are installed
> > > Any takers?
> > 
> > Probably I can take this. 
> > 
> > We need ruby-switcher to keep in sync versions for ruby and gem via
> > alternatives system. Other thing i would like to keep in sync and switch
> > with ruby version is /var/lib/gems/*/bin/. Can we manage it via
> > alternatives system too?
> 
> I don't think we should have different alternatives configurations for
> the the various ruby-related binaries. If a user decides that she wants
> "Ruby 1.9", then ruby, irb, gem etc, should all be the ones provided by
> Ruby 1.9; I think that irb/gem/etc should be slaves of the choice for
> /usr/bin/ruby.
> 
> IMO such ruby-switcher tool is an unecessary layer on top of something
> that already does what we need to be done, and has years of testing
> (i.e. the Debian alternatives system).
> 
> Lucas, could you please ellaborate on why you think we should have
> different alternatives for each Ruby-related binary?

I couldn't find a way to implement it. For ruby1.9.1, it would work. But
all slaves from a master alternative need to be in the same binary
package AFAIK, so we can't have a master alternative alternative in
ruby1.8 that controls a slave one in libgems-ruby1.8.

(But maybe I just missed something)

- Lucas


Reply to: