Bug 362336

Summary: software managment: yast insists on installing unwanted programs [package status, protect]
Product: [openSUSE] openSUSE 10.3 Reporter: macias - <bluedzins>
Component: YaST2Assignee: Stefan Schubert <schubi>
Status: RESOLVED INVALID QA Contact: Jiri Srain <jsrain>
Severity: Normal    
Priority: P5 - None    
Version: Final   
Target Milestone: ---   
Hardware: i586   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description macias - 2008-02-15 21:32:01 UTC
Today scenario: I would like to delete gcc41 and relatives (i.e. xxx41) but I would like to keep pdftk. Seems straighforward right?

-> xxx41 -> delete 

accept -> pdftk will be refreshed -> cancel then

-> pdftk -> protect (keep)

accept -> pdftk will be updated (???) -> cancel then

-> pdftk -> yast resetted it to refresh -> protect

accept -> pdftk will be updated (???) -> cancel then

Now, what user is supposed to do to keep ("do not touch") package if not setting "protect"? Please fix this and follow the user choices if they are made explicitly -- it is the difference if something is selected automatically and when user says "do this for that".


If anyone is curious, I found out the "solution". I searched for pdftk, thus narrowing the list only to it, I set a taboo status, which was converted to "protect" (so visually it was the same as before) and then I hit "accept". This time it worked.
Comment 2 macias - 2008-02-19 09:35:35 UTC
I don't have those packages any longer but I can explain the case with details.

There were gcc41, gcj41 and pdftk was built when those two were installed on the system. There were no Requires: fields in the rpm spec so pftk dependencies were based on library files (from gcc41 and gcj41).

Obviously when I wanted to remove gcc41 and gcj41, pdftk would no longer run (lack of needed libraries) but nevertheless I didn't want to refresh pdftk (to version which uses gcc42 and gcj42), so I set the protect status.
Comment 3 macias - 2008-02-19 09:52:08 UTC
PS. But IMHO the test case is irrelevant -- the problem is: is the auto-solver able to override flags as protected or taboo? It should not be able, but it is.

So there is no checking against those flags in the code.
Comment 4 Stefan Schubert 2008-02-19 10:01:26 UTC
These checks are implemented in the code. So either there is a bug or there are some missunterstandings.
Without that testcase I cannot do very much.
As you have already solved this problem by "protecting" the package I would suggest to close the bug as invalid.
For Code 11 we will have a new solver where this problem will be handled completely different.