[Rubygems-developers] Repackaging a Gem for other Package Managers (e.g. RPM, deb, conary, etc.)

Mauricio Fernandez mfp at acm.org
Wed Jan 24 14:45:42 EST 2007

On Wed, Jan 24, 2007 at 12:06:11PM -0500, Scott Parkerson wrote:
> I'm trying to come up with a relatively good way to take a Gem and
> re-package its contents for other package managers. I've seen a
> Gem2Spec tool for converting Gems to RPM spec filesout there, but
> would like to dig a little deeper. My specific area of interest is
> Conary, which is *not* a household name (yet).
> Specifically, I need to know a few things:
> * The best way to unpack a gem into a temporary root directory. My
> guess is to use something like
>     gem install <package> --force --ignore-dependencies --no-wrappers \
>         --install-dir <temproot>

$ tar xfO rcodetools- data.tar.gz | (mkdir ROOT && cd ROOT && tar zxf - 2>/dev/null); find ROOT

(more reliable than using gem install)

> * Once the temporary root is there, I can then dissect the gem and
> pull appropriate things and stuff them into their appropriate places
> (e.g. the stuff in lib under the gem should be put in
> /usr/lib/ruby/site_ruby/, the docs in
> /usr/share/doc/<packagename>/{ri,rdoc}, etc. Binary wrappers will have
> to be re-written to work with the native system, I guess (e.g. what
> Debian did to /usr/bin/rails).

There's no guarantee the sources will be organized in any particular way (some
packages do not have lib/, for example), so you'll have to check this on a
package basis.

> But all this is moot if it's still possible to write code which can
> only be run as a Gem. Is Rubygems source-intrusive (i.e. will having
> code that has require 'rubygems' bust everything without gems
> installed and the code being, well, where gems expects)? If so, that
> means whatever I repackage has to do surgery on the code, which seems
> suboptimal.

Code packaged in gems often does
  require 'rubygems'
without rescuing a possible LoadError exception, so you might have to install
RubyGems or a phony rubygems.rb.

Older code relied on autorequire and used require_gem 'gemname' without the
corresponding #require. This has been replaced by #gem (and autorequire is
gone) but it'll take a while before such code disappears completely (if you
bump into it, you don't want to repackage it anyway).

Applications and libraries which access data files will most probably have to
be modified, since at the moment there's no standard solution to the "DATADIR
problem" which works on RubyGems and everywhere else.

Mauricio Fernandez  -   http://eigenclass.org   -  singular Ruby

More information about the Rubygems-developers mailing list