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

[Toshio Kuratomi]

On Dec 21, 2012 2:25 AM, "Bohuslav Kabrda" <bkabrda at redhat.com> wrote
>>
>> 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).
>

After reading your whole post the first thing I need to make sure of is
that when you talk about abi and api here you are talking about the c
library correct?  You are not talking about the other things that the
python(abi) virtual provide covers or the things that the ruby(abi) as
currently written is intended to cover?

Second, when you talk about minor feature enhancements, that includes the
things that I mentioned? (Changes to the ruby language, api additions,
deletions, and changes to the ruby stdlib, changes to the filesystem layout
that have visibility to other ruby packages or ruby users).  Is it policy
that those types of changes are allowed or do they just slip in once in a
while because no one realized that a particular change would have that sort
of effect?

>> 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).
>
> Ruby stdlib is shipped with the interpreter, types are part of the
interpreter - they can be changed as explained above.
>

Thanks further thoughts/questions as a result of this included above.

>> 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?
>
> I mean "abi" as in "libruby.so.x.x", so for extensions.

Okay.  That's not how fedora traditionally used these virtual provides as
that would be redundant with the requires on the shared library.  The
virtual provides were used on the things that I mentioned instead (it
sounds like those things might be called "compat modes" by ruby people.  Is
that correct?)

> 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).

This sounds like a version of a compat mode isn't finalized until the last
cruby release of that version is released?  Does compat mode cover both the
stdlib and the language or just the language?  How long does jruby lag
behind cruby in terms of implementing these features?  Is compat mode
canonized in the cruby and jruby code or is it just a convenient concept?

>>
>>
>> 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.
>
> As mentioned, I would prefer having something like "ruby(interpreter)"
provided by both cRuby and JRuby. This would be required by all Ruby
packages.

Does that also cover changes to the ruby stdlib, filesystem layout, etc?
If so, it should simply be a rename of ruby(abi) for cruby and packages
that depend on it.  Adding jruby to the mix, i'm not yet certain of how
much compatibility there is here.  I'm also not sure how much
incompatibility we're willing to push onto users.

Packages with implementation specific extension would then require
"ruby(abi)" or "jruby(?)" (maybe just jruby).
>
If I understand what you're saying here, there's no point to ruby(abi) in
those circumstances.  Extensions would depend on certain versions of the
shared library (which is what you seem to have thought ruby(abi)
represented) and they probably also need to depend on ruby(interpreter) or
whatever virtual provide we use for the combination of language features,
stdlib apis, filesystem layout, and other things that determine if a
package will install and run with an installed interpreter.

-Toshio

>
> --
> Regards,
> Bohuslav "Slavek" Kabrda.
>
> --
> packaging mailing list
> packaging at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/packaging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/packaging/attachments/20121221/a0414176/attachment.html>