Whither RPM and RubyGems?

When one works in a mono-cultural technical environment then one may adopt processes and policies that fit but one approach. Package managers like rpm are a wonderful tool for providing consistency, the fundamental requirement for predictability, provided one only has to master one. Having to deal with many package managers for many different environments presents a set of challenges of an entirely different order; particularly for a development team working in a single language.

In any project there is always a limit to the resources available. Expertise with multiple package management techniques, while no doubt a valuable attribute to possess, does not seem highly valued among most application developers I have encountered. Further, the resources needed to obtain such expertise are probably more profitably employed elsewhere. System administration people of course take a different view but their POV is always post hoc. In general, developers are interested in getting something that works, more or less, out the door on time, more or less.

Finding myself on differing sides of the fence from time to time I have formed a somewhat pragmatic view of this situation. Ruby, like Perl, provides its own packaging system that is cross-platform. Why then repackage the same functionality in such a fashion such that it is only usable on one? This is simply not economical. The reasons usually presented for doing so I find are not compelling when it is trivial in Ruby to require specific gems from specific sources at a specific version.

To my mind, repackaging Ruby gems and Perl modules is essentially ritualistic in nature. Their value is more apparent, or entirely apparent, rather than real. Packaging the language itself together with is essential libraries and support tools? Without doubt this is the proper thing to do and I agree that this should be handled through the system package manager. Packaging language extensions and modules? I am not convinced that a system level package manager is necessary in most, or even desirable in some, cases.

Let us consider the history of Ruby-on-Rails. It can hardly be argued that having a stable development environment, such as CentOS, is not beneficial to any development project given that it frees resources from maintenance of the platform itself. However, I began with RoR-0.0.? on CentOS-4 sometime in early spring 2004. Ruby 1.8.5 had to go and I never did find a package for 1.8.7 in any repository that I cared to use. I was constrained to build my own version of Ruby; using checkinstall to produce an rpm package suitable for deployment on all of our CentOS-4 servers. But repackaging RoR itself? Given the frequency of releases of RoR, and of the many support gems that kept creeping into it, that would have been a major effort and frankly one of questionable worth.

Is the answer then to switch platforms to a less stable, if more current, OS distribution simply because one cannot find a suitable package for the present platform? Or does one spend the resources saved by using a stable platform learning the package management techniques for that platform and then force fitting the results of a gem update into a different package format simply to re-install the exact same code in the exact same place? Even when successful one is still faced with the task of learning the package management systems for all, or at least some, of the intended target platforms? Where exactly is the benefit?

Package management is generally a good thing and one that should only be departed from after careful consideration. It is not however a panacea. There are things that package management does not do well. Handling extensions and modules for a rapidly evolving application sometimes falls into that category.