On Thu, Jul 28, 2011 at 12:19 PM, Chris Lalancette <clalance(a)redhat.com> wrote:
On 07/28/11 - 12:09:58PM, Sergio Rubio wrote:
My personal view is that per Fedora release cycle, we should have a single
stack of ruby + rubygems that is "known good". For example, on Fedora 16 we
are going to be shipping ruby 1.8.7, plus rubygems for rails 3.0.9, and all of
the dependencies for that. Everything there should be tested together and
at verified to work together.
Yeah, understand. Makes a lot of sense from a QA perspective. However
the proposal does not change that IMO.
I mean, you can still have ruby-base ( fictitious package ) pulling
the default and well tested 1.8 stack.
The trick here is that Fedora could provide an 'alternatives'
mechanism to switch between ruby implementations easily (i.e.
'ruby-switch system' or 'ruby-switch 19', etc), since they can be
installed in parallel. Some sort of RVM but using packaged ruby
In addition, we also provide rvm for those who want to use alternatives
to the "known good" stack; that will allow them to mix and match gems that
come from the packaging, along with gems that they get from rubygems.org
Sure, RVM is great and flexible. However building a ruby
implementation when installing is very expensive, so it's far from
ideal in some scenarios.
Finally, we should think about packaging ruby 1.9 as an alternative to ruby
1.8, possibly calling the package ruby19 and using alternatives to switch
between the two (like python and python3).
If we did all of that, would that fit your use case? If not, I'm not sure
what you are proposing, could you explain further?
Yeah, I've been doing exactly that
) with some other ruby
implementations also. However it's not enough I believe, we need to go
a step further.
i.e. If I have a Chef stack installed, I'd love to be able to switch
from ruby18 to ruby19 or ruby-ee and be able to use Chef again without
having to use gem19 install chef (for example). In order to achieve
that, we need at least (please, correct me if I'm missing stuff):
1. /usr/bin/ruby needs to point to 1.9 ruby (using something like ruby-switch)
2. Native gems need to be rebuilt?
3. Existing pure ruby gems need to be available to 1.9
2. and 3. are kind of complex to achieve (but achievable I believe) so
the can be left out of the equation initially. Having a ruby
implementation 'switch' would be just great to get started.
Does it make sense?
ruby-sig mailing list