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

[Richard Hally]

Patrick W. Barnes wrote:
> On Thursday 31 August 2006 14:07, Richard Hally <rhally at mindspring.com> wrote:
>> Matthew Miller wrote:
>>> On Thu, Aug 31, 2006 at 01:32:05PM -0400, Bill Nottingham wrote:
>>>>> transaction != atomic transaction.
>>>> Please allow 4 to 6 weeks for package delivery.
>>> And, bizarrely, be prepared to end up with duplicate packages if there's
>>> a shipping problem.
>> and if you are not there to take delivery we will just dump it on your
>> driveway and you will have to spread it on your garden yourself. (wink)
>>
>> But seriously, without being too pedantic about it, "atomic transaction"
>> could be considered redundant. In database terms, a "transaction" can be
>> applied or rolled back and the integrity of the database is preserved in
>> either case. The smaller the "transaction" size the easier it is to
>> preserve the database integrity.
>>
>> Aw, never mind. We can just use that script on the yum hints page in the
>> wiki.
>>
> 
> Going further on the database terms, most of the work you do on a transaction 
> is *preparing* the transaction.  Once the transaction is *ready*, you have a 
> final opportunity to cancel the transaction before you *commit* the 
> transaction.  The commit stage is where the real work of the transaction is 
> done, and it is the one stage that you don't want to interrupt.  When you 
> decide to cancel a transaction after the commit stage has begun, you must 
> wait until it is done and then prepare a new transaction to roll the previous 
> one back, or there's no telling what sort of condition the database will be 
> left in.  In a typical RDBMS, you can usually prepare and commit the 
> reversing transaction very easily, but that's not always the case.
> 
> In yum, the stages of downloading the headers, calculating the dependencies, 
> and retrieving the packages are all part of preparing the transaction.  Once 
> the packages are downloaded, the transaction is ready and yum begins to 
> commit the transaction.  Just like in a database, you do not want to kill yum 
> while the transaction is being committed.  You can cancel it beforehand, you 
> can roll it back afterwards, but you shouldn't be interrupting it.
> 
> 
Yes to all of the above.
  The thing I'm trying to get across is that "the Transaction" should be 
multiple *smaller* transactions so that if one of them fails the others 
will not be affected.
Think of the case where there are say 64 packages to be updated. After 
all the downloading, all ~128 operations are packed into *one* 
transaction such that there are 64 update operations *followed* by the 
64 cleanup operations. Suppose yum seg faults on the second cleanup 
operation the remaining 62 cleanup operations do not happen! Leaving the 
well known "rawhide baby-eater" of many half-updated packages. Simply 
rerunning yum does not pickup where it failed. (as it does during the 
download/preparation phase)

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."

HTH
Richard