Bugzilla – Bug 246976
Can't set status from "update" to "protected"
Last modified: 2007-09-03 15:32:07 UTC
Found by aj@ and gp@ : If a package has status "update" in the package selector, you cannot change it to status "protected"; it will stay at "update". If you change "update" to "keep" first, you can change it to "protected". This can easily be reproduced on any system. Change any installed package to "update" and try to change it to "protected". MAJOR because the workaround is not at all obvious to users and also very awkward if more than one package is to be set to "protected".
The UI is very simplistic and passive for those status changes -- it simply tries to set whatever status the user requested and then displays whatever libzypp actually did. The UI calls selectable()->set_status( newStatus ); and then retrieves the status again with selectable()->status(); and displays the corresponding icon. My guess is that the zypp::ui::Status transition from S_Update to S_Update is either buggy or missing completely in zypp::ui::Selectable.
(In reply to comment #1) > My guess is that the zypp::ui::Status transition from S_Update to S_Update Should read: from S_Update to S_Protected
The same thing happens in the NCurses UI (as expected).
(In reply to comment #2) > Should read: from S_Update to S_Protected Shure you switch to S_Protected? Or S_Taboo? (If S_Taboo: Does it work if an explicit user candidate is set?)
Yes, sure it is S_Protected.
As trivial as this bug may seem, it has quite serious consequences: If user chooses to update installed package that comes with some license agreement (e.g. flashplayer), he must accept the agreement again. If he decides to reject it, the package status should be set to Protected and nothing should be installed (that's the expected behavior) Instead, package status remain at Update and package is installed at the end, even though the license agreement has been rejected. I guess, nobody came across this 'side effect' so far, because we all just accept license agreements by default ;-) Coolo, please have a look at this and decide the severity. I've been advised to make this a blocker...
Isn't Duncan working on something very similiar? I'm declined to set severity to blocker if all developers working on this are on vacation and this has been this way since about forever
Not a regression, although not nice.
Not a regression == bug compatible. We just didn't know that, but now we *do* know... Not only developing software but also fixing old bugs is our task.
The transition "update" -> "protected" succeeded in so far as the installed package was indeed locked. The function just forgot to reset any candidates transact bit. Evaluating the status, these bits immediately lead to "protected", without a further look at the installed items status. Fixed in libzypp-3.22.1: Switching to "protected" any candidate transaction bits are reset.
Fixed