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

[Toshio Kuratomi]

On Mon, Jan 07, 2013 at 03:33:58AM -0500, Bohuslav Kabrda wrote:
>     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?
> 
> Well, when I say "abi", I mean the C library, but when I say "api", I mean the
> pure Ruby language, which can be interpreted by any Ruby interpreter. I think
> we need to distinguish these two - ruby(api) for pure Ruby libraries and ruby
> (abi) or jruby(???) for those that contain an extension.
> As for the second point, AFAIK they "slip once in a while".
> 
[snip]
> 
>     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?)
> 
> Yep, I think so.
> 
So problem 1)  The Ruby SIG finds ruby(abi) hard to understand.  We can
simply rename it to ruby(compat-mode) to resolve this.  There's no need to
make a new ruby(abi) virtual provide for the C extensions because the
automatic library dep finding should take care of that.  Requires
a guideline update (discussing here) and a mass rebuild of the packages that
provide and require ruby(abi).

The mass rebuild should be doable at this point in the cycle.  If we
run into issues deciding on the rest of the proposal we should decide on
whether to make this rename of virtual provides separately (and first) so
that it can go into a mass rebuild.  (mass rebuilds are usually done several
weeks (up to a month) before alpha).

Now on to the harder parts of the proposal...

> 
>     > 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?
> 
> What do you mean when saying "finalized"? If you mean that e.g. features from
> 1.8.x to 1.8.y land continuously in the JRuby's 1.8 compat mode, then the
> answer to your question is yes.
> 
With "finalized" I was talking about cRuby but I may have misunderstood what
you wrote earlier (with "new features from the next version of cRuby").
I was trying to find out if cRuby continued to add things to the MAJOR.MINOR
compat mode after the release of the first MAJOR.MINOR:

For cRuby MAJOR.MINOR (example: 1.8), is it cRuby policy that 1.8.1,
1.8.2, 1.8.3, etc do not have changes that affect compat mode?  No new
features or changes to existing ones that mean that code written on 1.8.0
will/will not run on 1.8.3?  What about the opposite: is there policy about
adding and changing features so that code written on 1.8.3 will run on
1.8.0?  Is this policy frequently broken by accidents or rarely?

If I re-read what you wrote to apply to jRuby instead of cRuby, then I have
another question:  how do compat modes line up with jRuby releases?  Does
jRuby only ship releases when a compat mode is 100%?  (It sounds like the
answer is no since you mention that no release of jRuby support fork(), for
instance).  Is there some compat-mode-completion criteria for shipping
a release of jRuby?

If we don't have 100% compatibility the present structure of virtual
proivides is not well adapted to a shared compat-mode virtual provide.
(Similar dangers exist in python where, for instance pypy is close to
compatible with python2 but has a few corner cases:
http://pypy.readthedocs.org/en/latest/cpython_differences.html ).  I don't
believe we have precedent as to "how compatible" something would need to be
to share this type of virtual provide but in general, the right thing to do
is to err on the side of caution in order to protect the end user.

Debian has a method that they use for their python stack that is pretty
complex and a little hacky that might be usable.  It requires packagers to
manually mark their package as being compatible with certain versions of
python and then the needed module files are symlinked into the library paths
for the compatible python versions when the package is installed.  Something
along these lines is a lot more work to setup but may be another
possibility.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/packaging/attachments/20130107/a7e6aaa1/attachment.sig>