The Ruby World Domination Plan

[Jeroen van Meeuwen]

On 02/03/2010 07:39 PM, David Lutterkort wrote:
> Reviving an old discussion.
> 
> On Tue, 2009-12-22 at 00:32 +0100, Jeroen van Meeuwen wrote:
>> - ruby-1.8.5 as shipped in EL-5
>> - ruby-1.8.6 as shipped in Fedora currently, and most likely also EL-6
>> - ruby-1.9.1 as targeted for Fedora 13
> 
> I don't take it as a given that we need to support two parallel stacks,
> since that leads to major gyrations. Do we have any idea how much
> breakage there is on a 1.9.x stack ?
> 

Actually, I don't. Most of all upstreams will have had to comply with
the 1.9.x series at some point, and to some extent, 'cause the ruby
developers started using it but I'm completely unfamiliar with how far
they actually are.

> There's only ~ 250 ruby and rubygem packages in Fedora - how about some
> sort of mass rebuild of these against a 1.9.x to see how badly things
> break ?
> 

For one though, ruby-shadow is one of those libs that apparently noone
ever uses or actively works on. We'd be looking at a potential small
heap of these kinds of problems.

>> - The ruby-<m>.<m>.<t> packages are going to provide:
>>
>>   1) ruby(ABI) = <major>.<minor>
>>   2) ruby(ABI) = <major>.<minor>.<teeny>
>>   3) ruby(API) = <major>.<minor>
>>   4) ruby(API) = <major>.<minor>.<teeny>
>>
>> The Ruby ABI is pretty stable in between teeny versions, but much less
>> so for the Ruby API.
> 
> I assume that the ABI/API distinction is there so that pure-ruby
> packages can depend on ruby(api) and only binary packages require
> ruby(abi).
> 
> Is that really necessary ? And how would packagers use that in a
> meaningful way ? Do we have examples from 1.8.x where that distinction
> would have been useful ? I think the main reason for these fine-grained
> distinctions is the desire for parallel Ruby stacks.
> 

While the ABI has always been stable pretty much, the 1.8.x series has
had some minor yet significant API changes. Long story short, I'm not
trusting upstream to handle this very well, even within a stable stream,
and so I want to provide a safe-guard for us and our consumers.

One would want to be able to specifically require the Major.Minor.Teeny
version of the stack in order to prevent the problem from happening (and
being able to act proactively by "missing dependency"). For us, we can
still go with Major.Minor requirements for 99% of all cases.

>> - Search paths are going to look similar to:
>>
>> /usr/local/lib{,64}/ruby/<major>.<minor>.<teeny>/
>> /usr/local/lib{,64}/ruby/<major>.<minor>/
>> /usr/local/lib{,64}/ruby/
>> /usr/local/share/ruby/<major>.<minor>.<teeny>/
>> /usr/local/share/ruby/<major>.<minor>/
>> /usr/local/share/ruby/
>> /usr/lib{,64}/ruby/<major>.<minor>.<teeny>/
>> /usr/lib{,64}/ruby/<major>.<minor>/
>> /usr/lib{,64}/ruby/
>> /usr/share/ruby/<major>.<minor>.<teeny>/
>> /usr/share/ruby/<major>.<minor>/
>> /usr/share/ruby/
> 
> Besides the multi-version issues (which we'd probably keep even if we
> only support 1.9.x), there are two issues with these directories:
> 
>       * Ruby and Fedora have differing conventions for the location of
>         binary packages: /usr/lib{,64} for Fedora, and $arch subdirs for
>         Ruby
>       * Ruby and Fedora have differing conventions for the location of
>         local files: /usr/local for Fedora, $sitedir for Ruby
> 
> We should cater to the combination of these conventions, not their
> union.
> 

What we do in Ruby now (the most recent set of packages in my
repositories) is make /usr/share/ be the vendorlib, and /usr/lib64/ be
the vendorarch. The sitelib and sitearch end up in /usr/local/.

> Finally, I don't think it's all that useful to add /usr/local variants
> to the search path, just in case somebody wants to use them. 90% of
> 'local' installs will be gem installs into random locations, in which
> people will have to set GEM_PATH/HOME - the other cases can be covered
> with a RUBYLIB setting.
> 
> With all that, I'd suggest a loadpath of
> 
>         /usr/local/lib{,64}/ruby/<major>.<minor>/site_ruby/$arch
>         /usr/local/share/ruby/<major>.<minor>/site_ruby
>         /usr/lib{,64}/ruby/<major>.<minor>/vendor/$arch
>         /usr/lib{,64}/ruby/<major>.<minor>/$arch
>         /usr/share/ruby/<major>.<minor>/vendor/
>         /usr/share/ruby/<major>.<minor>/
> 

The $arch, site_ruby and vendor are duplication.

The aforementioned modifications listed are actually done quite easily;
easier and cleaner then the modifications used to be moving everything
to %{_libdir} (but not %{_libdir} for 64-bit).

The question quickly became, how would we want to handle packaging a
.gem or .so package, provided we would have had multiple stacks. Now
that we're dropping that specific hurdle... It's a question of
rebuilding everything.

>> Preliminary packages can be found on:
>>
>> For Fedora 12:
>>
>> - http://www.kanarip.com/custom/f12-ruby/ and
>> - http://mirror.nl.kanarip.com/custom/f12-ruby/
>>
>> For Fedora Rawhide:
>>
>> - http://www.kanarip.com/custom/rawhide-ruby/ and
>> - http://mirror.nl.kanarip.com/custom/rawhide-ruby/
>>
>> That said, these packages could ruin your current Ruby stack (different
>> search paths and all that).
>>
>> Please be so kind as to test these versions and provide me with the
>> necessary feedback, so we can move things along.
> 
> Did you say 'get yourself a rawhide VM' ?
> 

It doesn't have to be rawhide, just something you're not doing any
serious Ruby work on; that's why I include Fedora 12 packages ;-)

In order to test I need to be able to yum -y remove \*ruby\* every once
in a while, or even the occasional rpm -e --nodeps / rpm -Uvh --force. I
can imagine you would not want to do that on your primary workstation,
and I can only imagine what pains you would create running a dedicated
Rawhide VM for it ;-)

-- Jeroen