Looking for a good RPM spec for Ruby

rubyonrails-core
1

Hi all,

I am working on a RubyWorks project [http://rubyforge.org/projects/rubyworks/\] which is essentially a shrink-wrapped package for hosting Rails applications on RHEL.

Internally, it's a Yum repository that contains RPMs for everything needed to run a Rails app, plus configuration files that tie all these pieces together. So that you can do "yum install rubyworks", then drop your application into some place in the file system and - bingo - it's magically hosted.

We need a decent RPM spec for Ruby, to adopt for our needs. Something using a buildroot, correct dependency versions, documentation paths etc etc. There are as many Ruby RPM specifications as there are Linux distros, it seems. I'm looking for a recommendation. Thanks in advance.

Best regards, Alexey Verkhovsky

2

doesn't RHEL include a ruby RPM?

http://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/ruby-1.8.5-5.el5.src.rpm

If you can't use that ruby, you should be able to start with their .spec file.

3

Thanks, Michael.

Yes, it does, but the one available for RHEL 4 (which is what most people have) is downright ancient (1.8.1). In fact, even RHEL 5 contains the original 1.8.5 release and a few patches, the latest of which is dated last December. With RubyWorks we intend to stay much closer to the official Ruby releases. So, we will need to package our own stuff.

As for the RHEL's RPM spec itself, I feel somewhat uneasy about splitting Ruby into multiple packages (ruby, lib-ruby, irb, etc, etc, etc). What's that for?

4

Yes, it does, but the one available for RHEL 4 (which is what most people have) is downright ancient (1.8.1). In fact, even RHEL 5 contains the original 1.8.5 release and a few patches, the latest of which is dated last December. With RubyWorks we intend to stay much closer to the official Ruby releases. So, we will need to package our own stuff.

As for the RHEL's RPM spec itself, I feel somewhat uneasy about splitting Ruby into multiple packages (ruby, lib-ruby, irb, etc, etc, etc). What's that for?

No idea to be honest, but I'd expect that it's for some internal packaging reason. The biggest downside with repackaging some stuff is going to be managing conflicts. Like the bad old days of ximian gnome VS redhat gnome.

Either way, good luck with the project :)..

5

Dear list, sorry for an off-topic. Please send further replies to me directly.

No idea to be honest, but I'd expect that it's for some internal packaging reason. The biggest downside with repackaging some stuff is going to be managing conflicts. Like the bad old days of ximian gnome VS redhat gnome.

Sadly, we are headed down that same path so far. RedHat Ruby vs RubyWorks Ruby.

I looked at all kinds of ways to resolve this conflict, to no avail. Every alternative I investigated creates more problems than it solves. E.g., giving "our" Ruby a different name solves the problem of conflicting package names, but creates a much bigger problem of conflicting executables.

Actually, it's not all that bad in practice (as long as our version numbers are bigger than RedHat's), but certainly far from ideal.

I'd love to simply depend on RedHat RPMs. Maybe one day they gets their stuff together on this subject... :frowning: