rpm-5.4.10-22.i686 loops forever when installing ntpd-4.2.6p5-5.i686.rpm
baggins at pld-linux.org
Sat Dec 1 23:12:48 CET 2012
On Sat, 01 Dec 2012, Jeffrey Johnson wrote:
> Good: The behavior is symmetric when permuted.
> The documentation states that $1/$2 are the number of pkg instances
> after the script is run. This isn't precise enough a definition
> when there is an ACID transaction with a 2phase commit/discard
> (as in rpm5).
> The definition of "installed" is the same (in rpm-5.4.10) as
> Is the database transaction committed?
> The commit depends on whether scripts/triggers
> (with the $1/$2 counts) succeed. In addition,
> the status of all scripts run during install
> is added to the header before being saved in an
> This leads to a chicken <=> egg behavior, where the
> header cannot be committed until the scripts are run
> and the script arguments can't be computed until the
> header is committed in the rpmdb.
> There is the further issue of what degree of isolation
> (and visibility) of concurrent transactions. The code
> as written has full degree 2 isolation; if the header
> is added to the rpmdb sooner, and pending/uncommitted
> data is made visible, then the counts would be as you expect.
> Until saved (and the ACID transaction is committed), the
> 0 being seen above is consistent with interpreting
> installed == header registered/committed
> (see the PSM_POST case in lib/psm.c,
> where the rpmtxnCommit() call is done as part of PSM_RPMDB_ADD).
> I'm inclined atm to prefer the above actual behavior to "fudging" an
> extra +1 for "legacy compatible" behavior; I'm sure we disagree here.
> Short answer: patch in an extra +1 (there will be two code paths in need
> of patching, check for symmetry as above) if you wish "legacy compatible" behavior.
Thank you for explanation and the patch, I tested it and it does bring back
"legacy compatible" behavior. We do need that.
Jan Rękorajski | PLD/Linux
SysAdm | http://www.pld-linux.org/
More information about the pld-devel-en