My favorite pet bug (2004): Yum mishandles Ctrl-C

Richard Hally rhally at mindspring.com
Thu Sep 7 17:19:46 UTC 2006


Jeff Spaleta wrote:
> On 9/6/06, Jesse Keating <jkeating at 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





More information about the fedora-devel-list mailing list