On Apr 13, 2008, at 10:48 AM, Ralf S. Engelschall wrote:

> On Sun, Apr 13, 2008, Jeff Johnson wrote:
>
>> [...]
>> If you add -Uvv instead of -Uvh, the FA_BACKUP and/or other elements
>> necessary to diagnose the behavior are displayed.
>
> I append you the complete stdout+stderr output of the "rpm -Uvv"
> command (just skip of some Lua and %pre/%post outputs you are not
> familiar with, they are just from the OpenPKG stuff -- but should be
> unrelated to this problem). Perhaps you can see more from this. I  
> know,
> it is hard to help in such a situation. But with a simple test  
> package I
> was still not able to reproduce this...
>

Thanks.

(aside) btw, I'm really looking forward to stealing a state  
encapsulation
from the OpenSUSE sat-solver to attempt to automate both QA regression
testing as well as fault analysis for the inetall/erase state machine  
instead
of reading -vvvvvvv spew. But  not yet ...

...

> D: fini      100664  1 (1000,1000)          60 /usr/opkg/etc/ 
> openpkg/managers;48021d4d backup
> warning: /usr/opkg/etc/openpkg/managers saved as /usr/opkg/etc/ 
> openpkg/managers.rpmorig
> D: fini      100644  1 (1000,1000)        1837 /usr/opkg/etc/ 
> openpkg/openpkg.com.pgp;48021d4d
> D: fini      100644  1 (1000,1000)        1860 /usr/opkg/etc/ 
> openpkg/openpkg.net.pgp;48021d4d
> D: fini      100644  1 (1000,1000)        1807 /usr/opkg/etc/ 
> openpkg/openpkg.org.pgp;48021d4d
> D: fini      100644  1 (1000,1000)          20 /usr/opkg/etc/ 
> openpkg/platform;48021d4d backup
> warning: /usr/opkg/etc/openpkg/platform saved as /usr/opkg/etc/ 
> openpkg/platform.rpmorig
> D: fini      100644  1 (1000,1000)          61 /usr/opkg/etc/ 
> openpkg/release;48021d4d backup
> warning: /usr/opkg/etc/openpkg/release saved as /usr/opkg/etc/ 
> openpkg/release.rpmorig
> D: fini      100644  1 (1000,1000)        6428 /usr/opkg/etc/ 
> openpkg/rpmlua;48021d4d backup
> warning: /usr/opkg/etc/openpkg/rpmlua saved as /usr/opkg/etc/ 
> openpkg/rpmlua.rpmorig
> D: fini      040755  2 (1000,1000)           0 /usr/opkg/etc/ 
> openpkg/rpmlua.d
> D: fini      100644  1 (1000,1000)       46317 /usr/opkg/etc/ 
> openpkg/rpmmacros;48021d4d backup
> warning: /usr/opkg/etc/openpkg/rpmmacros saved as /usr/opkg/etc/ 
> openpkg/rpmmacros.rpmorig
> D: fini      040755  2 (1000,1000)           0 /usr/opkg/etc/ 
> openpkg/rpmmacros.d
> D: fini      100644  1 (1000,1000)        7537 /usr/opkg/etc/ 
> openpkg/rpmpopt;48021d4d backup
> warning: /usr/opkg/etc/openpkg/rpmpopt saved as /usr/opkg/etc/ 
> openpkg/rpmpopt.rpmorig
> D: fini      040755  2 (1000,1000)           0 /usr/opkg/etc/ 
> openpkg/rpmpopt.d
> D: fini      100755  1 (1000,1000)       26631 /usr/opkg/etc/rc; 
> 48021d4d
> D: fini      100644  1 (1000,1000)         529 /usr/opkg/etc/ 
> rc.conf;48021d4d altname
> warning: /usr/opkg/etc/rc.conf created as /usr/opkg/etc/rc.conf.rpmnew
> D: fini      040755  2 (1000,1000)           0 /usr/opkg/etc/rc.d

This is basically what I need to see, that the file action was  
consistent with the behavior.

The next step is understanding how the FA_BACKUP state was achieved.  
That gets nastier,
because file fingerprints are involved, but I have some prayer of  
being able to chase
down a reproducer with a modest amount of info.

Could you give me a tarball with
    /var/lib/rpm
    the directories that contain all the files involved
    the package that you are upgrading

No guarantees, but I might be able to concoct a reproducer here from  
that info.

What I'm interested in looking at is the hash uniqification added to  
the rpmdb
join key that avoids certain problems with fingerprints in rpm. That  
change was added about a year
ago, and is the only significant code change for like 7 years in % 
config handling.

I don't expect problems, but I need to control for accidental hash  
collisions in order
to understand how FA_BACKUP was achieved.

FWIW, my personal opinion regarding %config handling is that its way  
past time
to design other means than adding .suffix when installing/removing  
files.

The existing %config handling always leads to "starange" and  
"bizarre" behavior reports,
and is increasingly not meeting expectations, basically because the  
idea that a
sysadmin is prepared to perform manual merges for %config files with  
add .suffixes
is not at all what is happening in practice for many years now.

73 de Jeff