On Oct 30, 2:14    
wrote:
> Luis Lavena wrote:
> > As your point may be valid, introducing a new command not only
> > requires testing but is too major to be something just for a y.z point
> > release.
>
> > I believe the priorities when installing gems should be 'platform-
> > specific-one' and then 'ruby', contrary to what we have now (ruby,
> > then-your-platform).
>
> *Strongly* agree...and I also believe any gem that depends on C
> extensions which only work on MRI should not be the default "ruby"
> platform, since they obviously don't work everywhere. Historical
> reasons, I know...but we have to field at least a couple questions a
> week from people accidentally trying to install a C extension on JRuby.
>

The problem with that is the _unpredictable_ nature of all the other
"no ruby" platforms.

I alone need to deal with two: i386-mswin32 and i386-mingw32, don't
get me started with x86_64 for 64 bits Windoze...

So I don't see gem developers releasing gems that are the same for all
the known platforms except for "ruby" since ruby will generate this
situation in JRuby.

There is no easy way for this since the gems can have different types
of bundled extensions (via mkrf or extconf).

--
Luis Lavena