rebuilddb does not replace live database with temporary (fixed) database

[Lewis Rosenthal]

I've found:

[c:\]rpm --rebuilddb
error: temporary database /@unixroot/var/lib/rpm.rebuild already exists

Renaming rpm.rebuild and re-running works exactly once, leaving behind the temporary database dir, requiring manual cleanup.

[Andy Willis]

I am attempting to use --rebuilddb to see if I can clear up the issues with pthread and zlib where yum/rpm thinks that z.dll and pthr01.dll are not installed despite being there and the package being installed multiple times. I remove the packages and reinstall so that it is in just once and it will either fail to install due to lack of dependencies or install the packages again (which is how they become duplicated).
Anyhow, I created a rpm.rebuild which had a different and newer Packages file than in rpm. I had thought that I then had to manually replace the rpm folder with the rpm.rebuild if I wanted to use it.

[Lewis Rosenthal]

My initial assessment was incorrect. Thanks for making me look twice, Andy.

Indeed, starting off with:

 4-09-14  11:53         <DIR>      124  .
12-20-14   3:08         <DIR>      124  ..
12-19-14   2:51               0    124  .rpm.lock
12-19-14   3:23         688,128    124  Basenames
12-19-14   3:23          49,152    124  Conflictname
12-19-14   3:23         245,760    124  Dirnames
12-19-14   3:23         688,128    124  Filedigests
12-19-14   3:23          49,152    124  Group
12-19-14   3:23          32,768    124  Installtid
12-19-14   3:23          49,152    124  Name
12-19-14   3:23          49,152    124  Obsoletename
12-19-14   3:23       3,096,576    124  Packages
12-19-14   3:23          49,152    124  Providename
12-19-14   3:23          49,152    124  Provideversion
12-19-14   3:23          49,152    124  Requirename
12-19-14   3:23          49,152    124  Requireversion
12-19-14   3:23          49,152    124  Sha1header
12-19-14   3:23          49,152    124  Sigmd5
12-19-14   2:51          49,152    124  Triggername
       5,292,032 bytes in 17 files and 2 dirs

in @unixroot/var/lib/rpm, leaves off with the same contents after completion of rpm --rebuilddb, and then leaves:

12-20-14   3:08         <DIR>      124  .
12-20-14   3:08         <DIR>      124  ..
12-20-14   3:08         655,360    124  Basenames
12-20-14   3:08          49,152    124  Conflictname
12-20-14   3:08         245,760    124  Dirnames
12-20-14   3:08         688,128    124  Filedigests
12-20-14   3:08          49,152    124  Group
12-20-14   3:08          32,768    124  Installtid
12-20-14   3:08          49,152    124  Name
12-20-14   3:08          49,152    124  Obsoletename
12-20-14   3:08       3,112,960    124  Packages
12-20-14   3:08          49,152    124  Providename
12-20-14   3:08          49,152    124  Provideversion
12-20-14   3:08          49,152    124  Requirename
12-20-14   3:08          49,152    124  Requireversion
12-20-14   3:08          49,152    124  Sha1header
12-20-14   3:08          49,152    124  Sigmd5
       5,226,496 bytes in 15 files and 2 dirs

in @unixroot/var/lib/rpm.rebuild.

It is also not the presence of the .rpm.lock file in the rpm dir which is causing this.

[Yuri Dario]

The macros dbpath had been changed probably to allow testing and never restored to default values. Now code uses PID to create a temporary directory. URPO allows moving files at process end, but the temp dir is still in place. URPO needs some work to implement delayed rmdir().

fix rebuild code. ticket#99.
Committed revision r483.

[Yuri Dario]

URPO enhancement ticket: ​http://trac.netlabs.org/ports/ticket/50

[Yuri Dario]

We cannot rename databases because they are still locked by DB4 engine; EACCESS cannot be handled by urpo rename() because this breaks DosReplaceModule? usage in other sources.

use urpo renameForce() to rename locked databases. ticket#99.
Committed revision r486.