Bug 179543

Summary: Allow "yum search" if "yum install" already running
Product: [Fedora] Fedora Reporter: James Hunt <jamesodhunt>
Component: yumAssignee: Jeremy Katz <katzj>
Status: CLOSED UPSTREAM QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: katzj
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-04-19 20:38:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description James Hunt 2006-02-01 08:43:16 UTC
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:

Comment 1 Seth Vidal 2006-02-10 06:43:14 UTC
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.