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