Re: [Puppet Users] package conflict resolution method:

jcbollinger
Thu, 21 Nov 2013 14:32:35 -0000

On Tuesday, November 19, 2013 1:48:26 PM UTC-6, Matt Simmons
wrote:
>
> Hi John,
>
> I''m new around here, but I''m also in the same situation
as Tom, who
> started this thread.
>
> I was wondering if you could expound a little bit on the better solution
> that you mention. I write what I could refer to as "third grade
puppet",
> but I''d like to get better.
>
> When you suggest factoring out these resources into separate classes and
> modules, do you mean that, in essence, all possibly-shared resources should
> be in discrete modules or classes? How does that jive with modules included
> from Puppet Forge? Doesn''t that mean refactoring everything you
include
> there, as well?
>


I do not mean that possibly-shared resources must necessarily go into their
own tiny classes, though that would be one way to go about it.  I mean that
any given resource must belong to exactly one module, in such a way that
using the module via its public-facing classes and types cannot by itself
cause multiple declaration.

The module owning any particular resource might reasonably be one obtained
from the Forge, or it might be a home-grown one.  That multiple modules
might attempt to own the same resource is a thorny and longstanding module
compatibility issue -- two modules that both attempt to own the same
resource are not compatible.  Such a pair can be rendered compatible either
by making one module depend on the other for the resource, or by making
both depend on some third module for it.  Needless to say, that involves
modifying one or both of the modules.


John

--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit