Ruby 1.9.1 (or possibly 1.9.2)

Jeroen van Meeuwen kanarip at
Fri Oct 23 10:24:25 UTC 2009

On 10/23/2009 11:29 AM, David Lutterkort wrote:
> On Thu, 2009-10-22 at 17:13 +0200, Jeroen van Meeuwen wrote:
>> I did a blog post[2] on this subject, showing off a local build of a
>> compat-ruby-1.9.1 package I've made. I'm still working on some of the
>> other troubles all of that introduces, but I wanted to let you know
>> where I'm thinking it could be heading towards.
> Does that mean that you'd also want to change the packaging guidelines
> so that rpm's installs into the vendor directories rather than site ? I
> don't have a strong opinion either way, but think we should calrify
> that.

Agreed. I'm trying to follow what Perl does here, for the largest part, 
as it made extreme sense to me. I think it's a major improvement overall.

I think RPMs (rubygem-*) would install in site dirs, and `gem install` 
would go to /usr/local/*.

An alternative is that we consider "vendor" to be "Fedora Project", and 
package our own RPMs (ruby-*, rubygem-*) to go into the vendor 
directory, have site be the location for `gem install` and have 
/usr/local/* be the location for things "manually edited" if you know 
what I mean.

I'm not sure what is the best way to go either way, and so I thought 
let's hear some more from various other people involved with Ruby ;-)

> Also, what's everybody's sense of how best to do the switch ? Should F13
> ship with 1.9.x as the default ruby ? Do we need 1.8.x compat packages ?

I would like compat-* packages to be available. At least for 1.8.6 
('cause of next-gen EL), and maybe for 1.8.7 too (which != 1.8.6). 1.8.5 
is a little ancient, but if required/requested and time permits, or 
resources are funded, I would. This sort of compat-* packages could 
complicate and obfuscate (like that is why we don't have compat-python24 
in Fedora), but I also think it builds a better development platform 
("Hey, I can do this Enterprise Linux stuff on my Fedora Rawhide laptop 
just like that!"). I've even been thinking about using the alternatives 
mechanism, but from what I've seen so far, and giving it some thought, 
that is a long stretch.

-- Jeroen

More information about the ruby-sig mailing list