Description of problem:
When the RPM database is locked, Yum prints an error and does some traceback:
$ LC_ALL=C yum search libcurl
Loaded plugins: refresh-packagekit
error: cannot get shared lock on /var/lib/rpm/Packages
error: cannot open Packages index using db3 - Operation not permitted (1)
error: cannot open Packages database in /var/lib/rpm
Traceback (most recent call last):
File "/usr/bin/yum", line 29, in <module>
File "/usr/share/yum-cli/yummain.py", line 241, in user_main
errcode = main(args)
File "/usr/share/yum-cli/yummain.py", line 96, in main
File "/usr/share/yum-cli/cli.py", line 182, in getOptionsConfig
File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 180, in _getConfig
self._conf = config.readMainConfig(startupconf)
File "/usr/lib/python2.5/site-packages/yum/config.py", line 735, in readMainConfig
yumvars['releasever'] = _getsysver(startupconf.installroot,
File "/usr/lib/python2.5/site-packages/yum/config.py", line 802, in _getsysver
idx = ts.dbMatch('provides', distroverpkg)
TypeError: rpmdb open failed
Should probably exit gracefully.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Hm I am currently not able to reproduce it. Has this been fixed?
I have tried to install some packages and on another terminal ran `yum search libcurl` and AFAICT it works.
I think this was fixed and could be closed - or better: is there a way how to lock rpmdb for a longer time so I can test more?
I don't think yum search is a good test, as that gets a read-only lock on the rpmdb.
You probably want to do what initActionTs() does in yum.depsolver, and then run a package install in another window. But I'm not 100% sure.
Of course now I see the original problem was with search, so ignore that part of my comment :).
when I do:
>>> import yum, os, sys
>>> my = yum.YumBase()
I'm still able to install/remove package (on another terminal), so it seems to me the lock is not "hard". Or have I done something incorrect?
*** Bug 443277 has been marked as a duplicate of this bug. ***
Efforts to diagnose and fix this problem are ongoing at bug 495087, which has more detailed information you may find to be of use. Thanks for the report!
*** This bug has been marked as a duplicate of bug 495087 ***