While writing this proposal, the solution I was describing shrank in size
considerably - some work that had initially appeared to be prerequisites
turned out to actually be more like "it-would-be-nice-if".
I consider this proposal to be the simplest thing that could possibly work,
which is why my "caveats" section is twice as long as my "implementation"
section.
Problem:
Package managers recursively install dependencies. When a package (A)
managed by puppet has a dependency (B) that is also managed by puppet, the
package manager may, in some circumstances, install package B before package
resource B’s *puppet* dependencies have been met.
Solution:
This problem would be mitigated if puppet treated the package systems’
internal dependency graphs as `require` edges between puppet package
resources.
Implementation proposal:
When applying a catalog, for each package resource, use the `generate`
hook to invoke the package manager in dry-run mode. Parse the output of that
call into a list of packages the provider would install or remove as
dependencies. Use that list to create puppet `require` edges to any package
resources in the catalog with a matching package name and the same provider.
Caveats:
Package dependency resolution may change in the middle of a catalog run.
Modern package managers use complex resolution rules - installing package
“A” may change which of several possible dependency resolution paths package
“B” takes - if default dependency “C” conflicts with “A”, then alternate
dependency “D” may get installed instead. There is no way of querying
package managers for this sort of interaction. Also, other resource types
can change the dependencies of packages (by changing the configuration of
the RPM repositories, for example), causing the generated dependencies to
become stale and possibly incorrect.
Unfortunately, puppet must current processes all generated resources and
relationships before any resources are applied to the system. In fact,
puppet must be able to construct a list of the all resources it is going to
apply **in the order it intends to do them** before any work is done at all.
Future puppet development may relax these restrictions - an algorithm
has been proposed elsewhere that would remove the need to sort the resources
before starting to apply them. Once that was implemented, something like
`generate` or `autorequire` could be called immediately before applying a
resource to see if there were other resources that should be applied first.
Unresolved Issues:
This process becomes much more complicated if the user requests specific
versions of packages, as installing package A may cause package B to get
automatically upgraded. I believe dealing with this is beyond the scope of
the requested feature.
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" 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-dev?hl=en.
