Jeff Spaleta wrote:
On 9/6/06, Jesse Keating <jkeating@xxxxxxxxxx> 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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
