[Fedora-packaging] Ruby guidelines draft - further discussion

[Toshio Kuratomi]

On Tue, Apr 3, 2012 at 10:45 PM, Bohuslav Kabrda <bkabrda at redhat.com> wrote:
> Hi Toshio,
> ----- Original Message -----

>> 1)  As of ruby-1.9, the rubygem module is shipped as part of the ruby
>>     standard library which is an acknowledgement by upstream that
>>     rubygem
>>     is needed to install almost any other ruby library.  We should
>>     simply
>>     patch the rubygem library in the ruby standard library with the
>>     changes
>>     to make it compatible across interpreters.
>
> That's not as easy as it sounds. In terms of sustainability, this may become a nightmare to support, because we are talking about a pretty decent amount of patches. That is why we are trying to make Rubygems upstream merge the JRuby modifications.

We'll have those patches either way.  Either the patches are applied
against the ruby-rubygem package or against the ruby (ruby-libs)
package.  We want to have the patches merged upstream in either case.

>
>>     The various ruby
>>     interpreters have to fork the standard library when they create
>>     their
>>     interpreters so the more we work with the standard library
>>     versions to
>>     make the standard library version of modules not need patches per
>>     interpreter, the more everyone benefits.  We can do this work
>>     without
>>     pushing a third-party module for rubygems or installing into a
>>     separate
>>     location.
>>
>
> I see your point here, but the standard library itself is not completely implemented in Ruby (in MRI Ruby, it has C extensions, in JRuby, it has jars). So we can put some effort into this, but it's not completely achievable, just considering the per-interpreter extensions. The Rubygems library is however 100 % Ruby and therefore can be adapted to work with all the interpreters (I took the time to go through all the JRuby modifications and it's obvious, that these can be merged with some amount of work). That is one of the reasons why it makes sense to take Rubygems out and make them interpreter-independent.

I'm not suggesting that all of the std library be made interpreter
independent.  I'm just saying that making sure that the rubygem
patches for interpreter independence that we're making get pushed into
the stdlib version of rubygem.

>> 2) Ship a rubygem package that has separate subpackages for each
>>    interpreter that places the code into the vendorlib for each
>>    interpreter.
>>    Apply patches to this as needed to get to the place where we have
>>    common
>>    code running on all interpreters.  This seems pretty close to what
>>    we're
>>    doing now -- it's just that we don't need to install into a
>>    separate
>>    location that all the ruby interpreters need to know about.
>>
>
> Interpreter-dependent Rubygems were the case up to F16, but this whole idea is about not doing it this way. As I have already mentioned, applying interpreter-specific patches may become very hard to maintain (should we have one Rubygems package with subpackages), so I wouldn't see that as an option.
>
> Really, having one Rubygems interpreter-independent package is the best direction that we can take this.
>
So you're not quite getting what I'm saying, I think.

The special case I'm seeing does not have to do with whether we work
on patching rubygems to be interpreter independent.  It doesn't have
to do with us getting those patches integrated with upstream.  I think
we both agree that both working towards interpreter independence and
having any patches we generate merged upstream are goals of this (they
fall under criteria #1 for a good special case).

What both of my proposals do, essentially, is simply remove the
special-case for where the code lives on the filesystem. They're
saying "all non-gem libraries live in the stdlib of each interpreter
if shipped with the interpreter or in the vendorlib if shipped as
third-party code."  As opposed to the proposal that the rubygem module
is special and therefore has the additional clause "as a specialcase,
the rubygem module lives in %{_datadir}/rubygem instead of either of
those places".  The code inside of any of these locations (with our
choice of whether to patch upstream for interpreter independence or
not) would be the same in all cases.

So what I'm trying to find out is why there's the perceived need to
special case the filesystem location of the rubygem module... not why
there's a need to patch the code.  (and then whether that perceived
need translated into a real need :-)

-Toshio