From: Aredridel <aredridel@...>
Date: 2005-09-21T08:05:17+09:00
Subject: Re: RubyGems in Ruby HEAD

> Right now, RubyGems represents a step backwards relative to Minero
> Aoki's setup.rb in many regards as far as repackagers are concerned.
> To state it simply, it is often more difficult to package something
> released in .gem format than in an equivalent tarball + setup.rb. I know
> this from my personal experience when repackaging a large number of
> libraries and applications [2] and most importantly from what several
> developers working on established repackaging efforts (Debian, FreeBSD,
> PLD, Suse) have told me. This is due to RubyGems breaking source
> compatibility with non-RubyGems system in several areas, including, but
> not limited to the following: 
> * lack of support for DATADIR 
> * obviously, require_gem 
> * the auto_require feature
> * in general, problems due to the new directory layout

Having Gems become standard as they are now is problematic for linux
distributors, because of the amount of effort to package them to play
nice with other software is high.

It's a break with backward compatibility to go changing require's
semantics if rubygems is automatically loaded, and if it isn't, we run
into more and more libraries and apps that won't work with non-gem
libraries.

Why not just use rubygems you might ask?

I maintain a small cluster ... I've got package management
infrastructure to roll out updates, with complete validation checks to
all the machines -- some seven hundred packages per machine, some fifty
of which are Ruby-related. Using two tools with vastly different mode of
operation would make the task of rolling out Ruby apps to those servers
an onerous one, and the existing tools work perfectly.

It's mostly the breaking API that bothers me: changing require's
semantics, and adding an ever-growing list of libraries that only work
with gems, thereby requiring all prerequisites to /also/ be gems, is
making packaging ruby libraries up efficiently problematic. Packaging
escapes the realm of ruby, and has tentacles into the rest of the
system.

With RMagick as a gem, and ImageMagick installed with RPM, if I upgrade
ImageMagick, RMagick breaks. With RMagick as an RPM as well, RPM throws
a dependency warning, and I can go fix the problem, instead of
discovering that my image thumbnailing application has been broken for
days because of the broken dependencies. Fixing that is out of scope for
rubygems -- it just won't happen, it cannot happen.

Rubygems works alright for pure-ruby packages, most of the time. The
edge cases, however, are not rare, and have some grave problems. I would
like to see those problems addressed, or at least make it so that those
who maintain projects whose scope does include non-ruby libraries can
make that happen.

Aredridel
Ruby packager for PLD-Linux (http://pld-linux.org)