What kind of package are you trying to make? I was able to build an RPM for openSUSE with a simple gem install using –install-dir and –bindir, then running rake to generate the Apache module. I simply bypassed the script because it was unnecessary, and used the same system the script uses, sans all the autodetection routines.

Thanks for the -install-dir, -bindir tip, wasn’t aware of those at all.

@Hongli

It would be nice if there was a way of doing everything manually instead of the packager (me) attempting to reverse engineer the install script and check for any changes in install logic on version upgrades.

RubyGems support build-root style installations. gem install –install-dir and –bindir will do the equivalent of Markus’s old buildroot patch, and fits a little better with the Gems way of doing things.

@Hongli

Actually, that might not be as hard as you think. The openSUSE build service let’s you use a single spec and control file to build native packages for tons of different distributions. I built a passenger RPM on lots of the SUSE variants this exact way, and it’s almost brain dead simple to do. If you want, I can expand the distros I build for and become a default package maintainer for this.

Thanks!

My problem with RubyGems is that it is a competiting packaging system to the one provided by the Operating System - it competes both on a file level (as the Packaging System provided by the Operating System tracks files) and package level. Rule number one says there has to be one packaging system responsible for everything and no libraries, applications, whatnot get installed without being packaged first.

For Java there is JPackage which does a great job considering the resources they have.
For Perl it’s relatively simple to package perl modules off CPAN.
For PHP (yay!) it’s relatively simple to package PEARs.

FWIW, it would be nice if RubyGems supported installing gems into a buildroot kind of like Perl’s MakeMaker. The guys at SuSE had a patch for it at some point (0.9.4 days) but it does not seem to have been accepted upstream.

Vendoring stuff is a double-edge sword, and one that a lot of people don’t understand well. You’re point about security updates shifting to application developers by vendoring is totally spot on. However, the problem is that application developers tend to do it too much, and don’t realize that they’ve taken on the responsibility of fixing bugs and vulnerabilities in those libraries! I think that purists adopt these views because they’ve been burned in one way or the other in the past, and so drift to the extremes.

I think that the open-source world has a harder time of managing software than the closed-source world in many respects. In a purely commercial setting, just about everything is vendored. However, commercial companies have support agreements in place with the people they vendor stuff from, and security updates are delivered to the application developer, regardless of version, and the app provider integrates that into their software. If the company sources software from an open-source project, they completely vendor it and keep tabs to make sure that they are current with bug fixes and security updates. In the open-source world I think the perception is that the upstream maintainer will fix the software, and everyone will just upgrade. This mentality discourages vendoring and it also discourages having multiple versions installed.

RubyGems is the best overall cross-platform package management system out there. However, it still has some warts, and I’m actively working to refine it. What I don’t want to happen to Ruby and RubyGems is what happened to Java, which is an absolute total NIGHTMARE. In java, everyone vendors libraries, and they also vendor the VM itself! I don’t know how many different versions of Java I need to have installed on a box to run applications. It seems that every app developer (especially the closed-source folks) has to have a specific version of the VM for their app. Noone has a good solution that I’ve ever seen for this. Interpreted languages fall prey to this more than any other (byte-code or source-based). The only well-known interpreted language that doesn’t have this versioning nightmare on their hands is Perl, and it’s interesting because they’ve dodged the issue by not having a major release is ages. (I don’t know if PHP has this problem, but then again PHP is 100% vendored in all aspects that I’ve ever seen). The Ruby community needs to break through and come up with at least a somewhat sane solution to this problem.

I also think that the reason that Ruby is catching more flak than, let’s say Java, is because Ruby is a wonderful, let me repeat, WONDERFUL system scripting language. It’s the first language I’ve ever picked up and said “wow, I actually enjoy programming in this”. However, for Ruby to be more than just another Web application environment, the community needs to embrace concepts that system builders and distribution maintainers deal with all the time.

Finally, on the FHS front, I just want to say: FHS is designed to help system administrators and builders, not developers. I like the idea of being able to perform nightly backups of /var instead of the entire machine; I like to be able to make /tmp a ramdisk instead of a hard drive; I like configuring Tripwire to lock down /etc on machines that have high security requirements. I like being able to NFS mount /usr (which is still done in a lot of scenarios!). So in a lot of ways, FHS is a good thing, and developers should help thier local sysadmin out if they can. What I dislike about the FHS zealots are in areas like arch-specific libraries. So what if a 32-bit library sits in /usr/lib64, if the system knows what’s going on? RubyGems understands how to select the right library at runtime, so there’s just no need to break up the software at such a fundamental level.

At the end of the day, I think that RubyGems, with some tweaks, will do an excellent job at maintaining Ruby libraries. I also think that it will integrate well with native package management. I’m spending what spare-spare time I have accomplishing just that with openSUSE.