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

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