[Fedora-packaging] purpose of ruby(abi), python(abi), etc

[Toshio Kuratomi]

On Dec 20, 2012 11:12 PM, "Bohuslav Kabrda" <bkabrda at 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).  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).

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?

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.

-Toshio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/packaging/attachments/20121221/43efe9f4/attachment.html>