Ruby 1.9.1 (or possibly 1.9.2)

[Jeroen van Meeuwen]

Hi there,

Having discussed Perl packaging changes for Fedora 13 with Stepan Kasal 
in Brno last September, during the Red Hat Developer Conference 2009[1], 
I found his ideas (or the Perl SIGs ideas) sufficiently interesting to 
experiment with myself in the case of Ruby.

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.

Have a nice day!

-- Jeroen

[1] https://fedoraproject.org/wiki/DeveloperConference2009
[2] http://www.kanarip.com/node/872

[David Lutterkort]

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.

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 ?

David

[Jeroen van Meeuwen]

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

[Jeroen van Meeuwen]

On 10/23/2009 12:24 PM, Jeroen van Meeuwen wrote:
> 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.

A correction on what I previously said;

/usr/local/ is -at least in the Perl plans- to include the "site" 
specific directory.

So, the searchpath would be like (if the Perl plans are followed):

/usr/local/lib{,64}/ruby/1.9.1
/usr/local/lib{,64}/ruby/
/usr/local/share/ruby/1.9.1
/usr/local/share/ruby

^^ (no site_ruby) because that is redundant)

/usr/lib{,64}/ruby/1.9.1
/usr/lib{,64}/ruby
/usr/share/ruby/1.9.1
/usr/share/ruby

^^ (no vendor_ruby because that is redundant)

In fact, the plans for Perl include dropping the version number altogether;

/usr/local/lib{,64}/ruby/
/usr/local/share/ruby
/usr/lib{,64}/ruby
/usr/share/ruby

Now this looks extremely clean!

compat-packages could just:

/usr/local/lib{,64}/ruby/<version>
/usr/local/share/ruby/<version>
/usr/lib{,64}/ruby/<version>
/usr/share/ruby/<version>

How does this look?

Where would gems go? From packages, of course, outside of /usr/local/. 
But where would "gem install" gems go? I'd say /usr/local/, but what do 
you think?

-- Jeroen