rpm-5.4.10-22.i686 loops forever when installing ntpd-4.2.6p5-5.i686.rpm

[Jeffrey Johnson]

On Dec 1, 2012, at 6:23 AM, Jeffrey Johnson <n3npq at me.com> wrote:

>> 
>> Both permutations are wrong, $1 and $2 should be 1 in both cases.
>> 
>> [root at sith RPMS]# rpm -Uvh test-0.1-0.1.noarch.rpm 
>> Preparing...                ########################################### [100%]
>>  1:test                   ########################################### [100%]
>> [root at sith RPMS]# rpm -Uvh test-target-0.1-0.1.noarch.rpm 
>> Preparing...                ########################################### [100%]
>>  1:test-target            ########################################### [100%]
>> triggerin:test-0.1-0.1
>> #: 2
>> 1: 1
>> 2: 0
>> 
>> [root at sith RPMS]# rpm -Uvh test-target-0.1-0.1.noarch.rpm 
>> Preparing...                ########################################### [100%]
>>  1:test-target            ########################################### [100%]
>> [root at sith RPMS]# rpm -Uvh test-0.1-0.1.noarch.rpm 
>> Preparing...                ########################################### [100%]
>>  1:test                   ########################################### [100%]
>> triggerin:test-0.1-0.1
>> #: 2
>> 1: 0
>> 2: 1
>> 
> 
> OK I will look this weekend.
> 


(aside)
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
rpmdb.

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.

(aside)
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.

hth

73 de Jeff