Opinions on rubygem subpackages

[Mamoru Tasaka]

Matthew Kent wrote, at 04/01/2010 02:38 PM +9:00:
> Hello ruby-sig!
> 
> I'm currently working on packaging Chef 
> (http://wiki.opscode.com/display/chef/Home) which has presented some 
> some interesting challenges and I need some advice.
> 
> Currently their primary distribution method and focus is rubygems, 
> though they have produced Debian packages. When using Chef via rubygems 
> the actual setup is done by downloading and running a 'bootstrap' tar.gz 
> which does a number of things all over the system (putting configs in 
> place, installing more gems etc). The goal of packaging Chef is to avoid 
> this arbitrary 'bootstrap' step and contain everything required to run 
> Chef within packages.
> 
> Packaging the gems is easy enough, but the daemons, configs and 
> directories it requires seem to fall outside of the scope of what the 
> current rubygems packages do (as far as I can tell).
> 
> For my first target, the Chef client, my thinking is to produce 2 
> packages - the main rubygem then a 'chef' subpackage that ships the 
> binaries, man pages, init scripts etc. Check it out here:
> 
> http://magoazul.com/wip/SPECS/rubygem-chef.spec
> 
> I couldn't find anything in the wiki about *not* doing this with 
> subpackages but I'm unsure if it would be frowned upon.
> 
> Thoughts?

Just after looking at your spec file, although I will perhaps throw some
comments about some packaging issues or so for your spec file if 
your spec file is submitted as it is, I have no objection to providing
sysvscripts / configs for such scripts by yourself.

Mamoru