----- Original Message -----
On Dec 20, 2012 11:12 PM, "Bohuslav Kabrda" < bkabrda(a)redhat.com > wrote:
I think that one of the questions here is "why 'abi' and not something
else?"
We currently enforce every Ruby package to have "Requires: ruby(abi)", but
JRuby doesn't in fact provide any ABI (I don't think the Java API can be called
ABI). Therefore it doesn't make sense for the pure-Ruby packages to require ruby(abi).
It'd be better to have something that would explain that all they need is _anything_
that can interpret Ruby, e.g. "ruby(interpreter)". Packages requiring ruby(abi)
should IMHO be only these that have C extension or are otherwise bound to cRuby.
Similarly, JRuby-only packages should depend on jruby (or its virtual provide, if we
choose to create one).
This sounds like a productive piece of discussion. So is sounds like you desire to
create as few packages as possible to create a full stack for c-ruby, jruby, and other
implementations of the ruby language.
What rpm dependencies are used for are to guarantee that when a user installs a package,
the things that package needs to run are also installed.
( Note: If I use "when" below, i'm asking what conventions exist to map
those types of changes to bumps in the version number of upstream releases.)
It's when we put these two things together that things start to get tricky. When does
the ruby language itself change? (For instance, if blocks were only specified with curly
braces in one version but could be specified with either curly braces or parentheses in a
later version.) (Another for instance, if a new keyword is added to the language).
The standard for Ruby language is the cRuby. E.g. Matz decides what appears and what does
not appear in next versions. Tiny versions keep the ABI and API mostly the same (e.g.
1.8.3 can run anything that 1.8.2 could, but 1.8.3 may have some minor feauture
enahancements, AFAIK), whereas minor and major versions may change both ABI and API (for
example 1.8.x to 1.9.x or 1.9.x to 2.x.x).
<blockquote>
Is the ruby stdlib shipped separately from the interpreter to users? Are types part of the
stdlib or the interpreter? When can those be added or changed? These are examples of the
types of incompatibilities that we use python(abi) for (rather than a true c-library usage
of the term).
</blockquote>
Ruby stdlib is shipped with the interpreter, types are part of the interpreter - they can
be changed as explained above.
<blockquote>
You say that jruby doesn't provide an abi. Are you meaning for extensions or the types
of changes mentioned above? Does jruby target certain revisions of the above that certain
versions of cruby have implemented at a certain version or is it a mixture of some
features from one release and some features from a different revision?
</blockquote>
I mean "abi" as in "libruby.so.x.x", so for extensions. JRuby always
supports certain version(s) - compat modes - of Ruby. Right now, it supports 1.9 and 1.8
(and new features from next version of cRuby continuously land in the latest compat mode,
so e.g. the 1.9 compat mode of JRuby may be in fact a bit different from cRuby 1.9).
<blockquote>
Depending on where we can get compatibility, it may make sense to have one virtual provide
or one for the interpreter and one for the stdlib or one for the interpreter and several
for the stdlib. We might also end up deciding to implement something similar to
Debian/Ubuntu's python-commons setup for ruby or deciding that building a full stack
from one version of the packageset is too hard to validate so having separate packages is
better in the long run.
</blockquote>
As mentioned, I would prefer having something like "ruby(interpreter)" provided
by both cRuby and JRuby. This would be required by all Ruby packages. Packages with
implementation specific extension would then require "ruby(abi)" or
"jruby(?)" (maybe just jruby).
--
Regards,
Bohuslav "Slavek" Kabrda.