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

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On 10/29/2009 01:48 PM, Matthew Kent wrote:
> I'm interested to hear any thoughts on potentially
> generating a bunch more ruby-* packages though.

I wouldn't lose sleep over adding 4 more ruby packages.

~spot

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging