5:32 p.m.
Hi guys,
after FUDCon, and then some more thoughts in private email and between
my ears, I think I might have the bare bones for a plan to attack the
Ruby challenge;
First of all, let me emphasize that the complete plan is based on the
fact we want different Ruby stacks to be available, namely those Ruby
stacks that someone might target (in development). That said, I think
the list of Ruby stacks one can target right now are:
- 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
The goal of this thread is to figure out what we should do in terms of
packaging, but having given it a little thought here's how I think I
would prefer to attack the problem. Please bear with me when I start of
rambling 'cause I don't know how to put this in an overview that
everyone understands (but we'll get there);
- Ruby packages themselves are to be named
ruby-<major>.<minor>.<teeny>,
as to not have to rename packages to compat-ruby every time a newer
M.M.T is released.
- A base 'ruby' (e.g., the package's %{name} == "ruby") package
will
pull in the default stack (targeted to be ruby-1.9.1 in Fedora 13).
- 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.
- The base directory for Ruby modules is going to be %{ruby_vendorlib}
and %{ruby_vendorarch}, provided through /etc/rpm/macros.ruby, resulting
in /usr/share/ruby/ and %{_libdir}/ruby/.
This is where packaged gems and library extensions to Ruby should end up
initially. If gems turn out to be compatible with one specific Ruby
version only, one can use %{ruby_vendorlib_186} (again provided through
/etc/rpm/macros.ruby), or if a gem is compatible with 1.8.x,
%{ruby_vendorlib_18} should be used.
gems and library extensions installed manually should end up in the
appropriate /usr/local/ directories, which will also appear first in
each of ruby's search paths.
- 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/
as to make sure that rubygem-foo can be packaged for all ruby versions
easily, while making the exception (ruby version specific patch?) is
also perfectly feasible (by putting another copy in the more specific
search path).
To illustrate my packaging points, I would appreciate if you look at the
following git repository, where I keep a couple of .spec files as well
as the macros.ruby file I intend to use:
git://fedorapeople.org/home/fedora/kanarip/public_git/ruby-specs.git
Along with that comes a git repository for Ruby itself, to be found at:
git://fedorapeople.org/home/fedora/kanarip/public_git/ruby.git
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.
Thanks in advance,
Kind regards,
Jeroen van Meeuwen
-kanarip