Issue #5319 has been updated by Nigel Kersten.
Nick Moffitt wrote:
> Nigel Kersten wrote:
> > The apt provider doesn't do what #4067 describes Nick. I think we're
> > talking past each other without understanding what the other is
> > saying.
>
> My reading of #4067 is that when any resource X depends on package A,
> and package A's actual package file depends on package B, puppet detects
> this somehow and adds the dependency to the chain (autocreating a
> resource?). So now X ultimately depends on B. This dependency
> resolution sort of falls out of using apt (or perhaps yum) as the
> provider to install A, no?
>
Just to address this point, I don't believe that's what it is describing at
all. The problem is that external package relationships that Puppet is not
aware of can result in the Puppet-specified relationships you specify no longer
being enforced.
"If you have RPMs A and B, where B depends on A and Puppet objects that depend
on one, or more, of the RPMs, then Puppet should automatically add relevant
ordering objects to properly order the RPM dependencies."
So a more concise example would be here, where package A requires package B in
the package management system.
<pre>
package { "A": ensure => installed, }
package { "B": ensure => installed, }
file { "/etc/b.conf":
contents => "...",
before => Package["B"]
}
</pre>
Because B gets installed when A is installed, and there is no relationship
between A and B in the Puppet manifests, File["/etc/b.conf"] may not
necessarily be applied before Package B as you have specified.
To look back at your previous comment:
"The situation I’m most worried about is one in which two packages have
conflicts/replaces relationships with one another. The apt provider will
happily install the first, then install the second (removing the first) and on
the next run it will re-install the first (removing the second) and then
re-install the second (removing the first again). Back and forth, forever."
I believe this is *exactly* what #4067 is aiming to fix. If A and B have a
conflicts/replaces relationship with one another in the packaging system, and
you've asked Puppet to install both, then Puppet should be aware of the
packaging relationship and insert it into the user-specified relationships from
the puppet manifests.
In that case Puppet would tell you that you have a conflict, because you do.
You can't ensure both packages are installed because they conflict with each
other.
Does that make more sense?
----------------------------------------
Feature #5319: ensure => selected for packages requiring interactive
installation (dpkg/apt provider at least)
https://projects.puppetlabs.com/issues/5319
Author: Nick Moffitt
Status: Needs design decision
Priority: Normal
Assignee: Nigel Kersten
Category: package
Target version:
Affected Puppet version:
Keywords:
Branch:
At times there are packages with catastrophic failure modes when they are run
noninteractively, particularly when working with dpkg. As a result I propose
the following option in package providers, presented from a dpkg standpoint.
If a package resource is ensure => selected, it will have exactly the same
status behavior as ensure => installed, but the installation process will run
'echo "${packagename} install" | /usr/bin/dpkg --set-selections'. This will
cause the package to be installed the next time an administrator interactively
runs "apt-get dselect-upgrade".
This allows configuration changes for a particular package to be held back
until that package is installed interactively.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
