You made some great points. I realized I’d never been bitten by the precondition on EPEL because we handle that at server provisioning time with a custom Knife bootstrap, but obviously not everyone’s going to do that.

I’m not entirely sold on arbitrary length multi-stage runlists yet because of the complexity, but maybe adding a third phase between the existing compile & execute — and locking it down to that — might be appropriate for Chef.

Peter, I do love your psql cookbook and doing things that way. Modules that require compilation against exact versions of devel libraries are fine for serious software developers where subtle ABI breakage is a problem, but are a poor fit for doing routine system administration. Nobody is going to change “CREATE TABLE” significantly between versions. Perhaps another solution would be to convert the database LWRPs to use the command line tools rather than Gems?

Multi-stage builds (where one stage builds the tool, that drives the next stage of the build, that builds the tool for the next stage etc) are a problem across a range of build tools. There has been some interesting academic work on the subject but I have yet to see a practical build tool that solves this nicely. A poor mans version would just be the ability to have an array of runlists. Phase 1 runlist would build and converge before Phase 2 runlist built and converged before Phase 3 runlist built and converged etc. This would also make it quite easy to cut down builds on nodes. i.e. The Deploy apps into appserver phase could be Phase 3 and you could chose to run just that phase for quick deploys.

[1] https://github.com/realityforge/chef-psql

I agree that sticking stuff in compile time is a bad idea. I have a commit to postgresql::ruby recipe that moves everything into execute time rather than compile time. https://github.com/bryanwb/postgresql/commit/52c4aa005ac78a9f10651f77c4f2034347ba26fb

I tend to agree w/ you that chef_gem running at compile-time may cause more problems than it solves

Perhaps a patch to chef_gem resource could be added so that you could choose to run it at run-time rather than compile-time. That said, running resources at compile really screws up your perception of how resources are processed, at least it does for me.

great post! we’ll have to get you on the foodfightshow to talk more about this topic

I don’t believe the CBC’s decision to force the use of the Flash player was technical; I know for a fact you have lots of smart techies working for you at the Mother Corp. You need to explain to the decision-makers that you don’t win loyal listeners by limiting choice and forcing platforms.

And as a national broadcaster, is there no way you can work with another national broadcaster (like the BBC or the NPR) to share R&D costs?