The Ruby World Domination Plan

[David Lutterkort]

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 ?

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 ?

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

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

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>/

> 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' ?

David