big_package is a disaster waiting to happen

[howech]

We have been using big_package as a dumping ground for library installs that we are pretty sure that we would like to have, but we don't really have a good reason for them being there. This is bad for a couple of reasons. Reason #1, other cookbooks may be silently relying on packages that are installed by big_package, so removing big_package from a node's run list may cause failures because of the undocumented dependency. Reason #2: the libraries in big_package have their own depencencies, which could easily conflict with dependencies found in other cookbooks.

[temujin9]

+1

[mrflip]

+1

[mrflip]

fixed -- packages are now defined as node metadata attributes.

The pkg_sets attribute group defines a) what package sets to install, and b) the
contents of those package sets.

You choose the package sets to install by setting node[:pkg_sets][:install] -- by default,

default[:pkg_sets][:install] = %w[ base dev sysadmin ]

Targets for package resource go in node[:pkg_sets][:pkgs][{set_name}], targets for gem_package go in node[:pkg_sets][:gems][{set_name}], and so forth. For instance, the 'base' group is defined as

default[:pkg_sets][:pkgs][:base] = %w[ tree git zip openssl ]
default[:pkg_sets][:gems][:base] = %w[ bundler rake ]

In your clusters file or a role, you can both specify which sets (if any) the machine installs, and modify (for that node or role only) what packages are in any given group.

Defining pkg_sets is distributed -- anything can define a 'foo' group by setting node[:pkg_sets][:pkgs][:foo], no need to modify this cookbook. Selecting which packages to install is however unambiguous -- you must expressly add the set 'foo' to your node[:pkg_sets][:install] attribute.

[mrflip]

(see https://github.com/infochimps/cluster_chef/tree/master/site-cookbooks/big_package -- which will probably soon be https://github.com/infochimps/cluster_chef/tree/master/meta-cookbooks/pkg_sets )