From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: If a "yum install" is in progress, and a user attempts to run, "yum search <keyword>", the search fails with the error: Existing lock /var/run/yum.pid: another copy is running. Aborting. It would be great if yum could be updated to allow a search command to be run whilst an install/update is in progress. The search is effectively a "read-only" operation, so this should be possible to do. The only issue I can think of is how you handle the "status/repo" field in the search output. For example, the lines below are snippets from the output of "yum search python": python-simpletal.noarch 4.1-1.fc4 extras pyorbit.i386 2.0.1-4 installed If I was in the process of running, "yum install python-simpletal", and I then ran, "yum search python", if you allowed multiple invocations, it could either disregard the in-progress transaction and simply report python-simpletal as "extras", or if it was really clever, the "yum search python" command could query the in-progress "yum install python-simpletal" transaction, and show the 3rd field as "locked" or maybe even "install-pending" / "update-pending" / "delete-pending", or similar: python-simpletal.noarch 4.1-1.fc4 install-pending pyorbit.i386 2.0.1-4 installed Version-Release number of selected component (if applicable): yum-2.4.1-1.fc4 How reproducible: Always Steps to Reproduce: 1. yum install <package> & 2. yum search <package> 3. Actual Results: Existing lock /var/run/yum.pid: another copy is running. Aborting. Expected Results: yum could allow the search to return the results as expected. Additional info:
not really. We need to be sure the sqlite db's aren't being written to at the same time, so we have to lock at least for the duration of the db create. I don't see this as terribly onerous, though.