RubyGems TODO

Okay, we've shaken out the closets and moths are everywhere, on all of 
our noses.  I'm really glad to hear the comments by the repackagers, 
because I honestly don't know what they're dealing with.  I've never 
been a part of that whole turnpike before and it seems pretty tedious 
and delicate.

So, what needs to happen with RubyGems to neutralize everybody?

1. The DATADIR problem: Mauricio has offered good solutions in 
http://tinyurl.com/b7yo9.  In addition, we could get rbconfig and 
RubyGems to jive alot better.
2. The `gem setup' and `gem list' requests seem reasonable: 
http://tinyurl.com/8ju7c.
3. The semantics of require / having to require 'rubygems' when using gems.
4. Compatibility with linux distro packing systems, reducing the amount 
of work necessary to repackage gems.

Concerning the last one, Aredridel said:

> 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.

What if a gem could be treated like a tarball?  Like you run `gem 
extract RMagick-0.2.6.gem' and you're left with a directory containing 
the distribution and a `gem-setup.rb' which could do the work of 
handling gem-related installation tasks while leaving the library 
distribution open to patching and custom installation?

_why