On Thu, Jul 28, 2011 at 12:19 PM, Chris Lalancette <clalance(a)redhat.com&gt; wrote: 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 implementations. 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. Yeah, I've been doing exactly that (https://github.com/frameos/ruby19-rpm) 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? Rgds.

On Thu, Jul 28, 2011 at 1:35 PM, Vít Ondruch <vondruch(a)redhat.com&gt; wrote: Yes, it's a good point, and probable makes a lot of sense from a Fedora packager point of view. It's also true that a lot of ops and devels out there (users, in any case) want to use Fedora/RHEL for their stacks and want to be able to use the ruby impl they prefer (cause provided impl is old, boring, or whatever reason) without having to resort to compiling stuff and manually tweaking the system. It's all about adding flexibility and upstream maintained ruby packages to Fedora while trying to hide some of the complexity and boring stuff that (some) users have to deal with when switching ruby implementations. Rgds.

2011/7/29 Guillermo Gómez <guillermo.gomez(a)gmail.com&gt;: That's the case with every ruby implementation out there. All of them have special features with their own benefits and drawbacks (performance, persistence, concurrency, bridges to other langs and frameworks, etc). Having sane defaults and supporting one ruby implementation makes a lot of sense. Discarding other ruby implementation cause user or the packager doesn't care does not IMO.

It would seem to me that the standard ruby should be the default Ruby installation. From here it is just a question of what version? What do we have that still depends on Ruby 1.8? I think puppet had problems with 1.9 for a while (and maybe it still does)... But what else? What is preventing us from (or a better question may be "why haven't we" ) shipping 1.9 in parallel with 1.8? We've shipped python3 as an option for a couple of Fedora releases now, it would seem to me that we could/should be doing the same with Ruby. Even Debian got this out the door before us, as Squeeze has ruby1.8 and ruby 1.9 both available in their standard repos. So this isn't unprecedented or infeasible.