Home_greyopenFATE - openSUSE feature tracking > #306315
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Improve PK/zypper/YaST Big Lock

Feature state

openSUSE Distribution
Rejected Information
Rejected Information


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.

User benefit:

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.


  • Suggest packagekit to quit when it conflicts with yast sw_single (https://features.opensuse.org/309367)




icons/user_comment.png F. L. wrote: (9 years ago)

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.

icons/user_comment.png J. K. wrote: (8 years ago)

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.).

icons/user_comment.png R. U. wrote: (8 years ago)

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

icons/user_comment.png F. L. wrote: (8 years ago)

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.

icons/user_comment.png J. W. wrote: (8 years ago)

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. Bug #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.

icons/user_comment.png S. L. wrote: (5 years ago)

Instead of locking whole packaging stack we can lock only packages. Dependency and packages, which are touching by translation can be locked.

icons/user_comment.png D. M. wrote: (5 years ago)

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).

Last change: 11 months ago
Score: 10
  • Negative: 0
  • Neutral: 0
  • Positive: 10
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint