From: mathew <meta@...>
Date: 2005-09-24T12:34:07+09:00
Subject: Re: RubyGems in Ruby HEAD - Debian

Austin Ziegler wrote:

>I would be opposed to a "register" command in RubyGems. The better
>solution would be for repackagers to *use* RubyGems internally for Ruby
>.gem packages and acknowledge that it was installed that way. You've got
>custom install/uninstall scripts available, so why not use them?
>

I've just taken a look at the dpkg/deb documentation and pulled apart 
some examples. It seems to me that the process of converting a .gem to a 
.deb could be almost entirely automated:

1. Run 'gem specification [NAME]' to extract the gemspec.

2. Run 'gem unpack [NAME]' to extract the files, total their size.

3. Run a Ruby script which reads the gemspec as YAML and spits out a 
provisional dpkg control file, including the install size calculated in 
step 2. It can also spit out a postinst file consisting of 'gem install 
[PATH]/[NAME]' and a prerm file consisting of 'gem uninstall [NAME]'. 
The Debian package names would ideally be systematically generated from 
the gem names, e.g. Foo::Bar -> lib-foo-bar-rubygem.

4. Edit the dpkg control file, add the non-Ruby dependencies, and any 
architecture restrictions that apply. (The gemspec should list the 
non-Ruby dependencies, but you'll need to work out the corresponding 
Debian package names. The version of Ruby required is, of course, 
included in the gemspec, so that can be translated to the control file 
automatically.)

5. Pack up the gem and control/postinst/prerm files into your .deb file 
using tar and ar.

And that's it. You get a proper .deb package with description and 
version info and dependencies and everything needed for the install, and 
it calls the gem command to do the actual work. The only missing piece 
is to provide a way for RubyGems to tell APT about things installed 
directly from .gem files by the user; though if you provided gem2deb as 
a user tool you could probably justifiably ignore that problem.

I note that Debian's *binary* glibc and locales .debs use a shell script 
and the GNU localedef program to compile and install all the locale 
files from source.  It seems to me that that demolishes any argument 
that dpkg has to be used to install all the files of a binary package. 
If the locale package was built the way some people seem to be 
suggesting Ruby libraries need to be packaged, you'd have separate .deb 
files for every single locale, consisting of locale data pre-compiled by 
a dedicated team of Debian locale repackagers. People who wanted obscure 
locales would have to post requests to have them repackaged. Can we all 
agree that would be silly?


mathew