On Apr 5, 6:11 am, Christophe L <cl.subscript...@gmail.com> wrote:
> Hello,
>
> Thanks for your answer.
>
> I understand the restriction about resource name uniqueness, but I
> don't understand the practical usage of it on the package resources.
>
> Let's say there is two modules totally different, written by two
> different developpers, but both depending on the same debian
> package :
> the two developper wills use the simplified syntax of the package
> resource such package { "MODULE_NAME" : ensure => installed }, like we
> can see it on usual puppet sample on internet.
>
> Then, when an administrator will include the two modules, it will fail
> because the same package is defined twice, even if the description of
> the resource is exactly the same.
>
> It doesn't sound as a normal behavior to me, unless if a best practice
> is to never use the simplified syntax for package resource ?
>
> Or is there an other best practice for avoiding this situation ?Expanding somewhat on Andrew's response: >From a conceptual perspective, if two separate and independent modules both require the same package, then clearly it is incorrect to model that package as belonging to or being the responsibility of either module. It is a more fundamental resource than either module represents, else you would not have such a conflict in the first place. The correct solution, both conceptually and practically, is to manage the package via a separate module that both of the others rely upon. In your particular case, it looks like it would be very natural to create and use a "php" or "php5" module to manage all the PHP packages. Your "apache" and "cms" modules would then both depend on the new "php" module to ensure that the needed packages were installed. At the manifest level, suppose you put all the PHP package declarations in class "php::packages". Then both "apache::install" and "cms::installpackage" would put this line at the beginning of their bodies: include "php::packages" IMPORTANT: Puppet's 'include' function is *not* analogous to the C preprocessor's #include directive: it does not interpolate anything. It's much closer to Python's 'import' statement, which makes Python modules visible to other Python modules. If you don't necessarily need all of the PHP packages for every PHP user, as it appears may be the case, then you can additionally declare the PHP packages virtually in "php::packages". Then, after 'include'ing php::packages, your other modules would also 'realize' the packages they need. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
