On 9/6/06, Jesse Keating <jkeating(a)redhat.com> wrote:
> On Wednesday 06 September 2006 16:29, Richard Hally wrote:
> > If you were to separate the list of packages to be updated into
> multiple
> > smaller transactions so that package A would have its cleanup operation
> > follow its update operation and then the next *transaction* would
> update
> > and cleanup the next package, one transaction would not affect the
> other.
> > Of course, dependencies would have to be accommodated by including them
> > in the proper transaction. But that would still allow unrelated
> > packages to be in separate "transactions."
>
> This type of logic would have to go into RPM as its RPM that knows in
> which
> order to install the packages (and thus the broken up package sets). Yum
> should continue to be able to hand rpm a complete list of packages to
> install, rpm should handle that set in a safe way.
Regardless of which layer the logic goes, I have to ask how expensive
is it going to be time-wise to identify an optimal group of
transactions, seperated into distinct groups of inter-dependant
packages. I think we already have an example of this being done
sub-optimally, in the shell scripts listed in the wiki to help people
automate nightly updating.
http://fedoraproject.org/wiki/Tools/yum under Tips and Tricks. I
believe that the shell scripts listed there do exactly the sort of
mini-transactions being talked about, sub-optimally, as a side-effect
of doing sequential yum update commands.
-jef
Have you seen the --depcheck plugin that has recently been added to
yum-utils in Extras? That certainly is an improvement over the shell
script approach.
Perhaps a plugin that separates packages to be updated into separate
"yum transactions" would permit the user to make the choice between
speed and reliability/robustness/recoverability.
Richard