Re: Opinions on rubygem subpackages
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