Bug 822128

Summary:	lock override deletes lock
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	Felix Miata <mrmazda>
Component:	Basesystem	Assignee:	E-mail List <zypp-maintainers>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None
Version:	13.1 Milestone 1
Target Milestone:	---
Hardware:	PC
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Felix Miata 2013-05-29 01:13:43 UTC

To reproduce:
1-zypper ref
2-zypper al kernel-desktop # saves much upgrading time due to bug 786318
3-zypper rm kernel-desktop-3.7.10
4-answer to remove kernel-desktop in spite of lock
5-zypper -v dup

Actual behavior:
1-new kernel-desktop gets installed
2-kernel-desktop entry is missing from /etc/zypp/locks

Expected behavior:
1-new kernel does not get installed
2-kernel-desktop entry remains in /etc/zypp/locks

Comment 1 Michael Andres 2013-06-04 07:04:30 UTC

  Problem: conflicting requests
   Solution 1: do not keep kernel-desktop installed

You do not install/remove the package in spite of a lock, but you remove the lock rule to make the package installable/removable. It's the same behavior as in the UIs. I don't think we want to change it.

Comment 2 Felix Miata 2013-06-04 09:14:44 UTC

(In reply to comment #1)
>   Problem: conflicting requests
>    Solution 1: do not keep kernel-desktop installed

> You do not install/remove the package in spite of a lock, but you remove the
> lock rule to make the package installable/removable. It's the same behavior as
> in the UIs.

What UIs? IOW, what exactly can I do to reproduce so as to see behavior "in the UIs"? Maybe it needs changing too.

> I don't think we want to change it.

I think we do. If it is not to be changed according to comment 0, then the language in the possible solutions in answer to the question need to be changed so that it is clear what is actually happening:

     lock removal

rather than

     lock override

as it appears now.

     *Override does not equate to remove*

As it is now in M0 system overdue for upgrade to M1, even 'zypper -v --no-refresh rm kernel-desktop-3.8.2' with kernel-desktop locked produced:

1-no cmdline feedback indicating change to locks file in response to selecting "do not keep..." to indicate kernel-desktop removal from locks file. 
2-no indication of change to locks file in /var/log/zypp/history
3-2188 lines added to /var/log/zypper.log to sift through to discover indication of lock removal

cf. Mageia urpm behavior, which uses skip.list rather than a locks system to prevent automatic installation of enumerated packages.

Comment 3 Michael Andres 2013-06-05 03:07:21 UTC

(In reply to comment #2)
> What UIs? IOW, what exactly can I do to reproduce so as to see behavior

In the YaST software selector. Toggle state of a locked package will remove the lock. You don't get back to the locked state. You must explicitly re-apply the lock.

> UIs"? Maybe it needs changing too.

I agree that 'override' could be a more intuitive lock handling policy, but changing the policy is out of scope of a bugfix. We'd need to take this to 
FATE (https://features.opensuse.org) for discussion.


> language in the possible solutions in answer to the question need to be 
> changed so that it is clear what is actually happening:

Agreed.

Comment 4 Michael Andres 2016-07-26 15:57:36 UTC

Wording was fixed in libzypp-9.38.1:
  remove lock to allow installation of %s
  remove lock to allow removal of %s