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:

More Resources

Keep up to date with Rails on Twitter and This Week in Rails

Policies: Conduct, License, Maintenance, Security, Trademarks