Bugzilla – Bug 164445
[build 905] taboo is not persistent
Last modified: 2008-09-08 15:56:50 UTC
Maybe it doesn't work at all, but I only tested patches: I run YOU, it complains about gcc and glibc - so I unselect them (set them to taboo) and install another patches. When I run YOU again, gcc and glibc are selected for installation again.
Created attachment 77184 [details] YaST2 log dir bzipped
Created attachment 77189 [details] YaST2 log dir bzipped
Michael, why can't you comment? It's critical...
Or Klaus - could you comment this, when Michael is not available?
The logs show that patch:glibc-1249 is locked and not selected for installation. However, online update is restarted a couple of times (according to the logs) and the taboo state got lost. Looks like taboo state is not persistent.
No it's currently not persistent. Should be solved for SLES10.
*** Bug 150231 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > No it's currently not persistent. Should be solved for SLES10. Are you joking? A non-persistent taboo will upset several users (this is why this bug is marked as critical ;-) Please include the fix in 10.1 too.
The fix will of course go into 10.1. too, but it won't be present on GM, but shipped as update.
*** Bug 153337 has been marked as a duplicate of this bug. ***
*** Bug 186894 has been marked as a duplicate of this bug. ***
*** Bug 207892 has been marked as a duplicate of this bug. ***
*** Bug 170119 has been marked as a duplicate of this bug. ***
*** Bug 173622 has been marked as a duplicate of this bug. ***
*** Bug 115212 has been marked as a duplicate of this bug. ***
*** Bug 240112 has been marked as a duplicate of this bug. ***
*** Bug 94794 has been marked as a duplicate of this bug. ***
*** Bug 115376 has been marked as a duplicate of this bug. ***
This is a new functionality. Marking as Enhancement.
*** Bug 255642 has been marked as a duplicate of this bug. ***
This was promised one year ago - see comment #10. Please get this in asap! For YOU, this is a usuability bug and not a missing feature.
*** Bug 277149 has been marked as a duplicate of this bug. ***
Since bug 277149 is marked as a duplicate of this one, it not only that remembering "taboo" is broken but also "protected". If the user marks a package in YaST as protected one does so for a reason and not to have YaST update the package without warning. This is definitely not an enhancement but a bug! What sense does it make to offer the user to "mark as protected"-functionality if it is only valid for one YaST-session and forgotten when restarting it? If this is not a bug, who invented the "one session protected"-feature and for what?
I can confirm this bug for openSUSE 10.2. It's impossible to switch from state "keep" to state "protected". See also bug 246976. Would be nice to have that fixed in openSUSE 10.3.
It's just got a lot worse: the issue with the agfa fonts license on 10.2 is a good test case. On a newly installed 10.2 system which had all updates installed I added the agfa-fonts package. Next day the KDE panel's update watcher applet notifies me of 3 new updates, one being agfa-fonts. I play around with setting this to protected and/or unmarking it for installation. The exact sequence of things I tried I can no longer recover, net result is that the other 2 updates installed fine first attempt, but the agfa-fonts package is now immune to any treatment whatsoever. Meaning the system is now in a state where: 1) marking agfa-fonts as protected and clicking accept does nothing (good). This setting is not persistant (annoying bug). 2) Removing all tickmarks from the box and clicking accept does nothing (I think). 3) Making no change, leaving the package as marked for installation, and clicking accept, does nothing. Specifically, it does not install the update. 4) Because of 3), the suseupdater applet is rendered useless, because every morning there is at least one update to install.
In 10.3 you can add locks to /etc/zypp/locks file like kde* or kernel* > 3.5 After 10.3 it will be more integrated with the UI.
*** Bug 364449 has been marked as a duplicate of this bug. ***
Is this fixed, or not? Because in few days it will be closed as wontfix which is very awkward because this bug is simply valid.
Available in 11.0 *** This bug has been marked as a duplicate of bug 332853 ***
QA- To decide fate of which dupe to retain and investigate fix or no action but words from reporters only
Sorry if my comment was too short. As Duncan wrote in comment #28, on openSUSE 10.3 one has to manually maintain the file /etc/zypp.locks. Locks applied or removed by the UI are not synced back to this file. This was postponed. It is fixed in openSUSE 11.0 since libzypp-4.18.0. Locks can be added and removed via the UI, as well as via zypper. libzypp-4.18.0 (or a later) version was released as online update for 11.0 9. (see. bug# 332853) There is no further fix for 10.3. The solution from openSUSE 11.0 can't be simply backported, because we exchanged almaost all libzypp components in 11.0.
Closing for 10.3