On Apr 19, 6:08 am, Sans <r.santanu....@gmail.com> wrote:
> On Apr 18, 2:22 pm, jcbollinger <john.bollin...@stjude.org> wrote:> [ ..... ]
>
> > 1) The dependent package is managed by Puppet. In this case, you must
> > ensure it absent too, else you cannot achieve a consistent
> > configuration. You will either get Puppet failures or flip-flops
> > between whether httpd is installed or not. (I am fairly sure that
> > this is why the yum Package provider uses "rpm -e" instead of "yum
> > remove" in the first place.) To fix it, you have to ensure the
> > dependent package absent too, and in that case you can address your
> > original problem by twiddling the dependent package's dependencies.
> > For example:
>
> If I understand you correctly, how do one know about the packages that
> depend on a certain package?
Well that's part of a deeper problem, isn't it? If you don't know
what packages you might end up removing or why they're installed in
the first place, then are you really comfortable with blindly removing
them? I certainly wouldn't be.
> Even though someone may know about the
> "dependent" packages, do you mean to list all the packages with "no"
> parameter? Cheers!!
No, I don't mean that. For a very tightly-controlled configuration,
one might choose to declare all packages that should be installed and
to purge anything else, but that can be hard to maintain, and I
wouldn't recommend it unless you really need it. Most people don't go
that far.
I mean you test your manifests before rolling them out and collect
automated reports from the clients afterward, you troubleshoot
failures, and when you identify a package dependency that causes
removal of another package to fail, you add a
package { "unwanted-dependency":
ensure => absent,
before => Package["dependent-package"]
}
to the affected nodes' manifests. (Or if the dependency is already
under management then adjust its declaration as needed.)
Also, the frequency of such problems will be reduced if you take
firmer control of your machines' initial provisioning. For example,
your initial install might be the bare minimum needed to get Puppet
running, with everything else needed being installed under Puppet
control. Alternatively, do at least consider a provisioning system
that starts all your systems in the same, known state -- that way you
can solve the dependency issues once for that configuration and cover
the majority of package dependency issues that you will ever need to
handle.
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.
