From: Rick DeNatale <rick.denatale@...>
Date: 2007-05-08T05:23:29+09:00
Subject: Re: Gem-only releases

On 5/7/07, Jason Roelofs <jameskilton@gmail.com> wrote:
> I really do not understand this stance against Rubygems. It seems to me that
> the only problem they have with Gems is that there's no control over where
> gems are installed. Do they have the same problem with Pear (PHP), CPAN
> (Perl), and Packman (Python)?

I suspect that the key concept which the debian maintainers have is
summed up in this statement from
http://pkg-ruby-extras.alioth.debian.org/rubygems.html

    * Rubygems is source-intrusive. The require instruction is replaced by a
       require_gem instruction to allow for versioned dependencies.
       Debian and most other systems think that dealing with versioned
       dependencies outside of the source is a better idea.

I believe that some of their other arguments against gems are either
untrue, debatable or spring from the above.  Note that require_gem is
obsolete, but that's not really the point.

I'm not sure I see how gems violates the FHS. I think that the
problems are more with Debians use of the FHS.

The thing which gem does which seems unusual from the viewpoint of
packaging schemes such as debian and RPM is that it allows multiple
versions to be installed in parallel on the target machine.  As I
understand it, Debian strives to have a single consistent set of
packages installed at any given time with the packaging system
ensuring the consistency.  Another way of looking at this is that the
latest possible time to do version binding is at package
install/upgrade time.

On the other hand, this is problematical in a dynamically bound
environment such as is provided by Ruby.  The ability to have multiple
versions of gems installed and dynamically resolve versions at
run-time is powerful and fits right in with the other dynamic features
of Ruby.

I think that the debian opposition to gems is just another example of
programmers with exposure only to static languages missing the
differences between dynamic languages and what they are used to.


Just a personal observation.
-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/