[chef] Re: Re: RE: Re: Re: Re: RE: Augeas support

[Thom May < >]

On Tue, Feb 19, 2013 at 1:26 PM, Cassiano Leal < " target="_blank"> > wrote:

-----Original message-----
> From:Joshua Timberman <
 
 " target="_blank">
 >
> 
> 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 packaging system.

Basically, abstract notions of a functionality, whose actual implementation is delegated to one or more packages (or in Chef's case, cookbooks).

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?