Notes about "gems.eclass"

There are a few things you should be aware of before adding a new package using a gem instead of a "standard" tarball.

I created the eclass because Ruby on Rails is only fully supported as a gem. They provide a tarball also, but it doesn't have the full funcionality of a gem install.

Most packages should have no differences between gem and tarball, but Rails is kinda popular these days and can afford to make bold decisions like gem-only support. :)

So heres a few things you should know:
  1. I made the rake ebuilds install both a gem and tarball because some versions of Rails only work with a gem version of rake and I didn't want to break existing applications.

  2. If you are replacing an existing tarball-based ebuild with an ebuild using the gem eclass, make sure any packages that depend on it have the following in it:

    require 'rubygems'

    because existing packages won't find the gem version of it.

    Even if no other packages in portage depend on a package, users having code that required "foo" will break if we switch a tarball-based ebuild to a gem-based ebuild without using "require 'rubygems'", so we should probably put einfo in pkg_postinst for those cases.

  3. There is no unpack or compile stage when you install via a gem. Everything gets done during src_install. So if you want to patch something in the gem, for instance, you'll have to do it after its in ${D}. If you're installing a gem that compiles a library, that gets done in src_install. Thats not good, but rubygems has no commands to unpack and compile in stages, yet.

  4. There is a new project in the alpha stages called g-gem which will create an ebuild from a gemspec. I haven't tried it yet, but it looks nice. I can probably figure out how to implement unpacking and compiling in stages from looking at this code.