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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Patrick W. Barnes wrote:
On Thursday 31 August 2006 14:07, Richard Hally <rhally@xxxxxxxxxxxxxx> 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



--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux