This isn't just an optimization. There are cases where you must
resort to exec'ing yum when, for example, two interdependent packages
must be installed in the same transaction, or one incompatible package
must be replaced by another. Note that the latter entails installing
and removing in the same batch (transaction)
This is rare, and I think that an *explicit* mechanism for batching
might be adequate, but certainly doing so automatically where it makes
sense would be better.
Would it make sense to use stages to set the batching boundaries?
package {
foo:
stage => packages,
batch => true;
bar:
stage => packages,
batch => true;
}
for yum, this would entail opening a transaction on the first
batch-able package in a stage, and completing any open transaction at
the end of each stage.
This is explicit enough that users would have no right to be surprised
when some other resource with require => Package['foo'] is processed
before foo is installed, although with some extra legwork we could
detect and warn on that arrangement ("cannot require a batched
resource"). And it's simple enough that something like
Package {
stage => packages,
batch => true
}
in site.pp would allow users to, essentially, change the default.
This "batch" parameter is probably generic enough to become a
metaparameter, with a "batchable" attribute for types that can be
batched, along with a few extra methods on the providers. In general,
it would mean that the resource may be processed any time between
where it appears in the dependency ordering through the end of the
stage -- so a "no earlier than, no later than" relationship.
Dustin
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
