On 03/12/2012 10:49 AM, Stephan Kulow wrote:
+1 for what Klaus has written
Please note that you need to touch the spec files anyway for another ruby flavor (jruby might become interesting at some point, ree is fortunately dead for 1.9) or ruby version. So we can discuss again at that point what to do :)
Greetings, Stephan
I don't see the need for keeping 1.8 around. Lets go pure 1.9.x. Most deployments happen with rvm or rbenv anyways, so if someone needs an exotic ruby interpreter they can do it in the usual way. This is about the interpreter for the distribution. It is true that you get the same problem again when adding other interpreter flavors. But I think this problem has to be workarounded by sharing all gems across versions an interpreters just like Java does. The only reason to keep them separated by versions is that ruby 1.9 is bin-incompatible incompatible with 1.8. But this is mainly (AFAIK) because 1.8 exposed to much of its guts (structs). Interpreters like JRuby and Rubinius implement the C functons diferently therefore they would not work anyway with an extension that tries to use MRI "guts". IIRC Jruby already dropped the ruby version from the GEM_PATH in one of the latest development versions. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org