Comment 2 for bug 651524

I have also observed this problem in the context of testing RPMs using a new RPM database.
E.g.
script to reproduce:

WSDIR=/tmp/foobar
mkdir $WSDIR

mkdir "$WSDIR"/rpmdb
rpmdb --initdb --dbpath "$WSDIR"/rpmdb

cd $WSDIR

# Exercise (install RPM)
# we use --nopost so that we don't run the post install script which runs ldconfig.
rpm --dbpath "$WSDIR"/rpmdb --nopost --root `pwd` --relocate /opt=`pwd`/opt -ivh <something>.rpm --nodeps

Actual results on stderr

"error: can't create transaction lock on /tmp/foobar/rpmdb/__db.000"

I believe this is the same problem as described here because rpm -U
installs the RPM successfully.

I have found that it is not a problem for all systems or all RPMs.

I have observed it fails on the following setup (for a particular RPM):

brucea@:main/test/systemtest>rpm --version
RPM version 4.4.2
brucea@:main/test/systemtest>lsb_release -a
LSB Version: :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: RedHatEnterpriseServer
Description: Red Hat Enterprise Linux Server release 5.2 (Tikanga)
Release: 5.2
Codename: Tikanga

I have observed it works on the following setup (for a particular RPM):

brucea@:depot/emma/main>rpm --version
RPM version 4.4.2.3
brucea@:depot/emma/main>lsb_release -a
LSB Version: :core-4.0-ia32:core-4.0-noarch:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-ia32:printing-4.0-noarch
Distributor ID: RedHatEnterpriseClient
Description: Red Hat Enterprise Linux Client release 5.6 (Tikanga)
Release: 5.6
Codename: Tikanga

I believe it also works on the following setup (for a different RPM):

[brucea@uktnswg-ams-test01 ~]$ rpm --version
RPM version 4.4.2.3
[brucea@uktnswg-ams-test01 ~]$ lsb_release -a
LSB Version: :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: RedHatEnterpriseServer
Description: Red Hat Enterprise Linux Server release 5.3 (Tikanga)
Release: 5.3
Codename: Tikanga

I cannot currently confirm whether updating rpm to version 4.4.2.3 on the failing machine is sufficient to solve this problem.