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