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
(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
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(a)opensuse.org
To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org