On 01/07/2013 12:23 PM, Bohuslav Kabrda wrote:
On the first look, cRuby and JRuby seem to be an appropriate
candidates for using alternatives (which solves the problem of automatically generated
dependencies from shebangs and switching interpreters by root). But - thinking of it
further, I'm not sure whether cRuby and JRuby are alternatives. Reasons:
1. extension gems - there are gems with extensions
a) only for cRuby
b) only for JRuby
c) for both implementations.
Obviously, most of the cRuby-only extension gems are only usable with cRuby and vice
versa for JRuby (exceptions are gems that contain pure Ruby fallback when extension cannot
be loaded). For these extension gems, cRuby and JRuby are not alternatives, AFAICS.
The same apply for jre, mta and other alternatives.
Useing the first: there is general alternative "jre", but for sure there
are JARs which only works with Java 1.5 some only with 1.7, some only
with Sun, others only with IBM... Life is hard.
+1
2. pure Ruby gems using cRuby specific functions - some Ruby
functions, for example fork(), cannot be used on JRuby, because JRuby doesn't support
fork() - so if a gem uses fork, it only works on cRuby.
So cRuby and JRuby are mostly alternatives, but not completely. Therefore we (ruby-sig
folks) came up with an idea that we call multiruby [1], which allows user (a user who
knows what he's doing - for RPM packaged applications, packager will choose how to run
them, possibly modifying shebangs) to choose the interpreter on invocation. The intepreter
defaults to cRuby (also, compared to alternatives, this approach brings the benefit on
non-root user being able to choose/switch the interpreter). In this scheme, /usr/bin/ruby
would be a shell script that would route the commands either to /usr/bin/ruby-mri or
/usr/bin/jruby. I know that this is no standard mechanism, but it doesn't break any
expectations and brings some interesting functionality.
-1
This is IMHO bad move. This move the decision on what alternative will
be used from sysadmin to packagers. And I-as-sysadmin want to be
responsible for that.
--
Miroslav Suchy
Red Hat Systems Management Engineering