Feature changed by: Karl Cheng (qantas94heavy) Feature #306315, revision 21 Title: Improve PK/zypper/YaST Big Lock openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-07-16 11:45:36 reject reason: no resources for 11.2. Priority Requester: Important Projectmanager: Important openSUSE-11.3: Rejected by Duncan Mac-Vicar (dmacvicar) reject date: 2013-03-05 15:41:44 reject reason: not done in 11.3 Priority Requester: Important Projectmanager: Important openSUSE Distribution: Implementation Priority Requester: Important Requested by: Stephan Kulow (coolo) Partner organization: openSUSE.org Description: Currently, execution of any action by one of the package management tools blocks all others, in a "big lock" fashion". This is entirely acceptable when I am doing something with YaST, or running the PK applet, but it is very fastidious when it is due to background activity. Running zypper and seeing that lock message when nothing is being run by the user is very annoying (and is really the same for Yum on RHEL - but it still sucks :-) Can we improve the way PK refreshing causes everything else to lock up? I must say I expect upstream to be doing something about this... At the very least (and that's the M below for 11.3) we should inclrease the interval with which PK grabs the Big Lock. References: http://lists.opensuse.org/zypp-devel/2008-03/msg00075.html https://bugzilla.novell.com/show_bug.cgi?id=551761 + Relations: + - Suggest packagekit to quit when it conflicts with yast sw_single + (feature/id: https://features.opensuse.org/309367) Business case (Partner benefit): openSUSE.org: The lock interferes with Administrator activity at random moments, and is very aggravating. It would be a competitive detail over RHEL, as well as a customer satisfaction item. Discussion: #1: Federico Lucifredi (flucifredi) (2009-03-30 21:13:47) I am somewhat reluctant to give this an M, as I do not know if something can actually be done to improve this. It would certainly warrant an M if a good solution can be devised, as this is really annoying on both SLES and RHEL, and it would make us look good in the comparison. #2: Ján Kupec (jkupec) (2009-11-06 10:30:50) Even if one zypp app is running, one should still be able to use the other in read-only mode (searching, reporting needed updates from current metadata, etc.). #3: Ralph Ulrich (ulenrich) (2009-11-07 01:01:08) This would be really cheap a read only zypper: rypper: only read only action enabled Benefit: I can do some working tasks with zypper and while this works I am able to inform myself using: rypper se -s something #4: Federico Lucifredi (flucifredi) (2009-11-10 04:29:58) Probably looking at the frequancy with which PK grabs the Big Lock is worth doing... I don't care to be notified by a popup within five minutes of an update being released if that means that most of the time my zypper calls bump into the big-lock-surprise. Yast is a non-issue, people can figure out to close it. it is the PK grabbing that is annoying, and is equally on RHEL (YUM) and SLES (zypper), we should tone down the frequency of its checks. #5: Juergen Weigert (jnweiger) (2010-06-21 17:24:41) Rypper would not get my votes as a stand-alone tool. It requires the user to know its existance and purpose. Zypper having an exception handler and falling back to readonly mode by itself would get my vote, though. Another option could be to allow zypper to do a 'killall packagekit' when needed. BNC#456165 indicates no downsides for this 'suggested' approach. Lowering the frequency of PK runs eases the symptoms, but does not cure the issue. Giving user-triggered-actions priority over system- background-tasks cures it. #6: Sławomir Lach (lachu) (2012-08-11 11:36:22) Instead of locking whole packaging stack we can lock only packages. Dependency and packages, which are touching by translation can be locked. #7: Duncan Mac-Vicar (dmacvicar) (2013-03-05 15:44:20) Michael already started to work in a global lock that allows for read- only actions to happen without locking other read-only actions (eg. search). Once in place we will need to see what other non-read-only action can happen in parallel if they don't share protected resources (rpm database, solv files, etc). -- openSUSE Feature: https://features.opensuse.org/306315