On Tue, Feb 19, 2013 at 1:26 PM, Cassiano Leal email@example.com:
From:Joshua Timberman firstname.lastname@example.org
By all means, don’t use the community cookbook if it doesn’t fit your preference, use case, supported platforms or standards.
Totally understood. Unfortunately, when it comes to such a basic cookbook as Apache, that means foregoing a very large share of the benefit of Chef - too many community cookbooks depend on it.
I have been thinking about this problem for a while now. I believe that
what Chef needs here is something similar to Virtual Packages on the Debian
Basically, abstract notions of a functionality, whose actual
implementation is delegated to one or more packages (or in Chef’s case,
I really like the idea of “virtual” cookbooks. But…
The real problem here is that you then get into the API of the cookbook -
if I say I “depends apache2” then what i really mean is that i expect to be
able to call the apache2_module LWRP and have it do the right thing.
But what happens when the opscode cookbook changes the semantics of the
LWRP (and does it right, bumps the major version etc). How do you express
the version number of the LWRP? Do all apache2 cookbooks have to have the
same version number?
Or are we actually talking about a “SONAME” of a cookbook, which becomes a
collection of “symbols” (LWRPs in this case) with specific versions. Then I
can say I actually want apache2_module ~> 2.0 and don’t care about anything
else in the cookbook.
Or is this overthinking the problem?