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 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
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",
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 ?
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.