[Fedora-packaging] ruby/rubygem packagers - advice needed

[Matthew Kent]

Having some difficulty deciding on the right path for this package, 
need some advice.

ohai - http://wiki.opscode.com/display/ohai/Home

"Ohai detects data about your operating system. It can be used 
standalone, but it's primary purpose is to provide node data to Chef."

- Written in Ruby.
- Available as a rubygem.
- No standalone install via tar.gz + setup.rb yet.
- 6 dependencies. All currently packaged as rubygem-* packages. 5 of 
  which I'm the maintainer.
- Available in Debian/Ubuntu as 'ohai', packaged from source and uses 
  no rubygems at all.
- require 'rubygems' has been removed from the codebase, only time 
  it's loaded now is when the user installs via gems and it generates
  the little /usr/bin/ohai wrapper.

Options:

a) Package as rubygem-ohai from .gem

   Pro - Easiest method, rubygem-* dependencies work as is.
   Pro - As there is no setup.rb yet this may ease maintenance.
   Con - Different from Debian naming. ohai is also very similar to the
         'facter' package that puppet uses, should be positioned in the
         same way.
   Con - Can only use what's carried in the gem, eg: man page isn't. 
         Would have to carry as a separate Source. Could have unit 
         tests removed from the gem in the future if they grow too 
         large (upstream did this for another gem they produce).

b) Package as ohai from a checkout of the git tag, dependencies on 
   rubygem-* packages

   Pro - Common package name with other distros.
   Pro - Have access to install all content, including the man page.
   Con - Handcrafted %install.
   Con - Have to forever patch lib/ohai to load rubygems so the 
         dependencies resolve.

c) Package as ohai from a checkout of the git tag, dependencies on non 
   gem ruby-* packages

   Pro - Common package name with other distros.
   Pro - Have access to install all content, including the man page.
   Pro - No need to patch to load rubygems.
   Con - Handcrafted %install.
   Con - Will need to produce non gem sub packages for every 
         dependency, immediately adding 4 additional rpms to the repos.

d) ?

This decision making process is much the same for my main goal of
packaging Chef (http://wiki.opscode.com/display/chef/Home) but has 
bigger implications as it has way more dependencies, needs init 
scripts, it's own user, etc. Stuff that is probably beyond the scope of
rubygem-* packages (?).

I'm leaning toward option c) as I like the idea of using the unmodified
source in it's entirety, which once a setup.rb is added upstream won't
be that bad. I'm interested to hear any thoughts on potentially 
generating a bunch more ruby-* packages though.

Thoughts?

- Matt