(Not sure the best place to post this but doing it via twitter was getting
a bit long in the tooth. I figured this was as good a place as any)
So I’ve been using omnibus pretty heavily over the past week and I’ve
started to feel some pain points that I’d like to get input on.
Omnibus is obviously very focused on the idea of building fat packages for
Opscode’s various products. Not a big deal and totally understandable. It
feels like at this point though, omnibus has grown into a product in its
own right and has a community entirely outside of Chef users (folks are
packaging puppet this way, for instance). I feel like there’s a bit of
conflict in those two things.
Right now, the omnibus-software repo is the master source/fallback for all
things. I haven’t looked to see if this is hardcoded into omnibus itself or
if I’m missing something simple to override that. The software definitions
in omnibus-software are always going to be designed to be for
building/packaging all the bits of a chef-server/chef-client package.
They’re carefully curated to ensure they all play nice with each other.
This is great for reuse/community as long as the omnibus-software repo
versions of packages are what you need. But if they aren’t, you have to
start copying out individual software files into your own project. If you
have multiple projects internally that you build with omnibus, you have to
duplicate that effort across all the projects.
So I have a proposal that I think would at least help part of that (and
leads to a bigger question):
- Extended the project DSL to support defining an alternate source at the
project level as well as at the individual dependency level. Obviously the
sane default here (and sane default for fallback) is the opscode
omnibus-software repo. Something like this (in config/projects/foo.rb)
master_source ', :branch => ‘master’
dependency ‘erlang’, :source => '‘
dependency ‘nginx’ # checks local ‘software’ dir first -> checks
’master_source’ -> checks opscode upstream
This would allow me to reuse common components internally when other folks
want to build custom packages using OUR known good
The questions are if opscode would merge something like this functionality
being that omnibus is so sensitive to the needs of building chef packages
first and foremost? I read something like this:
“The first version of this project used Opscode’s tool, but they don’t seem
to take pull requests, so I enhanced bernd’s superb fpm-cookery to create
Omnibus packages, and switched this project to use it.” (from here:
And it gives me pause. As I said, I understand that omnibus exists to
support opscode and that is the primary driver. I’m just wondering if this
is something that others would value?