On Mon, Apr 26, 2010 at 9:17 AM, R.I.Pienaar <r...@devco.net> wrote:
>
> ----- "Douglas Garstang" <doug.garst...@gmail.com> wrote:
>
>> I wasn't able to get this to run for only CentOS. I tried a few
>> different things in the site.pp. I wish I could put a case statement
>
> site.pp is a special file, it doesn't get evaluated on every run the same way
> that classes would get.
>
> So variables like $operatingsystem can have an unpredictable value in some
> cases. Best to move this logic to a class.
It's been fine so far, but...
I really don't see how this would work. Let's say I created a class
called os::centos, and included this class anywhere I wanted to have
the package clean functionality for CentOS. Firstly, how do you
guarantee that the package refresh is performed before any of the
packages in this module are installed? By using the site.pp file I am
guaranteed that it will always run before yum tries to install
anything. Actually, I've always been a bit fuzzy on what happens with
a default Package{} in site.pp AND another default Package{} in a
module. What happens if both have a require => ? Which ones takes
precedence? Are both performed, or just one of them?
The first poster said he would include os::centos in his module. What
happens if the module might be running on either CentOS or Ubuntu? I
don't think 'include os::centos' will work so great on an Ubuntu
system. How do you make it dynamic?
Doug
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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.
