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?
Have you looked at http://elff.bravenet.com/ ? They have some chef packages though I am not sure how closely they align with Fedora Package Guidelines.
stahnma
On Thu, 1 Apr 2010 07:19:47 -0600, Michael Stahnke mastahnke@gmail.com wrote:
Have you looked at http://elff.bravenet.com/ ? They have some chef packages though I am not sure how closely they align with Fedora Package Guidelines.
Why yes I have! I wrote them :) They were quick hacks though to get Chef up and running. These new packages are far nicer in conforming to the Fedora guidelines and having some logical subpackages. I'm backporting them for use on Enterprise Linux here
Hopefully some of it can be branched for EPEL when I'm done testing.
Any concerns over the subpackaging method?
- Matt
I think the approach seems pretty reasonable. The spec looks clean, and easy to read.
As long you're not just sticking stuff in vendor, or running seperate gem installs, etc, I think your approach is fine.
stahnma
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
ruby-sig@lists.fedoraproject.org
-
Mamoru Tasaka -
Matthew Kent -
Michael Stahnke