Re: [Puppet Users] package conflict resolution method:

Thomas Noonan II
Wed, 27 Nov 2013 17:09:35 -0000

I personally went the tiny class route, creating a module with a bunch
of little classes for various packages.  I opted for this route as it
let me deal with naming differences between apt and yum, and let me do
repo dependencies for stuff in Epel.

Here is an example:
https://github.com/TJNII/puppet-commonpackages/blob/master/manifests/python/argparse.pp

I''m currently not making use of the forge, at this time I''m
still
rolling my own modules.  So that''s a bridge I''ll likely have
to cross
later.

--

On Tue, 19 Nov 2013 11:48:26 -0800 (PST)
Matt Simmons <bandman@gmail.com> 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?
>
> Thanks, and sorry for what I''m sure is an overly-basic question,
>
> --Matt Simmons
>
>
> >
>

--
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