Opinions on rubygem subpackages

[Matthew Kent]

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?

[Michael Stahnke]

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

[Matthew Kent]

On Thu, 1 Apr 2010 07:19:47 -0600, Michael Stahnke 
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

http://magoazul.com/elff_wip/

Hopefully some of it can be branched for EPEL when I'm done testing.

Any concerns over the subpackaging method?

- Matt

[Michael Stahnke]

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

[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