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

[Jeff Spaleta]

On 9/7/06, Richard Hally <rhally at mindspring.com> wrote:
> 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.

Its most definitely not an improvement over the shell script I use.
My shell script uses
dancing bear interactive spinner ascii artwork!

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

I'm still not convinced that the multiple transactions idea gains you
much in the way of recoverability, considering the minefield that is
scriplets and triggers. It would certaintly help minimize the amount
of duplicate packages listed in the rpmdb when segs happen before the
cleanup stage completes.

I have to admit that's one of my big pet peeves with large
transactions in rpm, whether that transaction is brokered by yum or
rpm -F or whatever.  When i do a fresh install, I tend to do the
backlog of updates in small groups (20 packages or less) to avoid the
possibility of that happening.  Once I have the backlog of packages
installed, I find that recovering from a segged daily or weekly update
run is managable, because the number of update packages invovled on
these timescales tends to be small enough.  What sucks, is running a
fresh install of fc5 right now, and then doing all the available
updates and having that update process seg, leaving duplicate listing
in the rpmdb for some significant fraction of the number of packages
in that single transaction.  It's tedious to clean out those
duplicates by hand, far more tedious than just doing the updates in
small groups to begin with.  And sadly its one of those things that
its freaking difficult to reproduce.

It might also serve well to compartmentalize package transactions
enough to help people, like myself, narrow down problematic package or
scriptlet operations that trigger segs on other people systems, which
are again not as reproducible across systems as one would like.

I'd be most interested in seeing how doing an optimal calculation of
multiple transactions affects system resource consumption on lower
ended systems.  I have no expectation as to whether or not it would
make a difference at all.

Just as another point of reference, I believe (and I may be mistaken
about this) the now aging up2date codebase made multiple transactions
in some cases, like if up2date saw an up2date update it would first do
that update and then run a second transaction for other updates.

-jef