Description of problem: Trying to initialize the RPM database or install an RPM using the --dbpath option to specify a private RPM database produces the output "error: can't create transaction lock on /var/lock/rpm/transaction", and the action is not performed. Version-Release number of selected component (if applicable): rpm-4.3.3-18_nonptl How reproducible: Attempt to initialize a private RPM database or install an RPM using a user-specified --dbpath. Steps to Reproduce: $ mkdir /home/myuser/rpmdb $ rpm --initdb --dbpath /home/myuser/rpmdb error: can't create transaction lock on /var/lock/rpm/transaction $ rpm -Uvh --dbpath /home/myuser/rpmdb somerpm.i386.rpm error: can't create transaction lock on /var/lock/rpm/transaction Actual results: Failure. Expected results: rpm shouldn't try to establish a lock on /var/lock/rpm/transaction when the user is explicitly specifying that they're using their own RPM database. Additional info: This works as expected under the version of rpm on RHEL3 (rpm-4.2.3-30_nonptl), and strace shows that this version of rpm does not try to access any files in /var/lock/rpm (unlike the version on RHEL4).
It appears that this can be addressed by setting _rpmlock_path in ~/.rpmmacros. While this is a workaround, I'd suggest that the bug here is that _rpmlock_path should default based on --dbpath rather than needing to be explicitly set in ~/.rpmmacros.
The erratum clearly mentions %_rpmlock_path for non-root cases and how to set using %dbpath: https://rhn.redhat.com/errata/RHBA-2006-0440.html Transaction lock issues using RPM with --root and --dbpath have been fixed. Note, to use --dbpath as non root, customers will need to define the %_rpmlock_path macro to a location that can be written to; future versions of RPM use '%{_dbpath}/__db.000'. RHEL 5 will use a dbpath based lock but for RHEL updates we try to be conservative so maintaining the existing lock location file for RHEL 4 was decided upon, whilst providing necessary information in the advisory. Thus we will not change this for RHEL 4. Please also note if you are a Red Hat Enterprise Linux customer and have an active support entitlement, you should be raising issues via Red Hat Support. https://www.redhat.com/apps/support/ This is so that appropriate prioritisation and assesment (eg for update releases) can be performed and so that support agreements can be met.
So this is in fact a recognized bug--thanks. Based on what you've said the plan of action is for it, I'd suggest that it should be closed as NEXTRELEASE, not WONTFIX. I can tell you that searching for "error: can't create transaction lock on /var/lock/rpm/transaction" on Google gives you 0 hits, searching for it on Bugzilla gives you one hit (this bug report), and searching for it on RHN gives you nothing that's relevant (and if the search is restricted to Errata only it gives you no hits at all). So I'd also suggest that adding a message about _rpmlock_path to rpm itself (perhaps just specifically when a non-root user is setting --dbpath and is about to get stuffed with the "can't create transaction lock" message) would be a lot more helpful than expecting people to track down the erratum you've cited and find the workaround it mentions. It's a simple (and conservative) thing to do, and you could keep Redhat customers from wasting a lot of time this way.
I just got pinged by Redhat support about this, and in reviewing Redhat's response here it doesn't make sense to me. The justification for not fixing this bug in RHEL4 was that it's the more conservative approach. But using --dbpath without an explicit setting for _rpmlock_path worked just fine in all RHEL4 releases up until RHEL4u4--so how can it be more conservative to leave it broken than to fix it?
I take it back--maybe it *has* been broken all throughout RHEL4, since it was RHEL3 where I last knew that it was working.
GA RHEL 4 shipped with: #define RPMLOCK_FILE "/var/lock/rpm/transaction" This is now configurable as documented in comment #2, but defaults to RHEL 4 GA default. RHEL 5 is configured differently. WONTFIX is used to indicated this bug is not being considered for the update release, according to our process.