Bugzilla – Bug 166881
solver should provide "dont delete" as possible conflict solution
Last modified: 2007-04-07 17:11:48 UTC
I updated beta9 to RC1. In the proposal, I got a package conflict: python-mad-0.5.4-1.pm.0 is locked and cannot be uninstalled. Konfliktlösung: ( ) unlock python-mad ( ) keep python-mad Choosing "keep" caused the dialog to appear again with the very same message. (bug?) "Unlock" caused the package to be deleted which I didn't want to. Therefore I decided to click "cancel" in the conflicts dialog. After manually changing the state of "mad" from delete to keep, the conflict was solved. Conclusion: The solver should have offered "do not delete mad" as possible solution. BTW: - the mad package is from SUSE 9.3 and survived the update to 10.0 and several 10.1 betas ;-) - python-mad is a packman package for 10.0
Created attachment 78583 [details] y2logs the y2log contains some [cboltz] marks with comments which should make navigation in the logfile easier ;-)
'do not delete' == 'keep'
The bug seems the non-functioning of 'keep'
(In reply to comment #3) > The bug seems the non-functioning of 'keep' That's one half of the bug. The other half is that the solver did not offer "keep $other_package" (python-mad != mad) which would have been the easiest solution. I would have expected the following options: python-mad-0.5.4-1.pm.0 is locked and cannot be uninstalled. Konfliktlösung: ( ) unlock python-mad ( ) keep mad <--- this was not offered by the solver :-( ( ) keep python-mad <--- this should be named "ignore conflict" - and _not_ show the same message again ;-)
In RC2, at least "keep" is working (as in: not producing an endless loop). However, I end up with broken dependencies because "mad" is still marked for deletion (because of "delete unmaintained") and YaST happily reports "all dependencies are OK" :-( The second half of comment #4 is still valid for RC2.
Created attachment 79787 [details] y2logs from update to RC2
The situation in RC3 is still as described in Comment #7. Fresh y2logs are available in attachment #80987 [details] of bug #171106.
*** Bug 170545 has been marked as a duplicate of this bug. ***
Of course we need a fix for this endless loop.
Your latest logfile shows that you have kept kdemultimedia3-mad and it worked correctly. I cannot see an error. I have additional made tests concerning update 10.0 to 10.1. I have installed packages from packman: kdemultimedia3-mad mad python-mad While running the update I have delete mad and all "keeping solutions" of python-mad and kdemultimedia3-mad have worked correctly. So I cannot reproduce the error. Please feel free to reopen it if it does still exists with RC3 ( yes, I know that the last logfile was from RC3), explain what you have done in the UI and add the concerning logfile. Somtimes screenshot would be helpful ( Use the expert button in the dep-problem popup) So, I set it to worksforme with RC3
(In reply to comment #13) > While running the update I have delete mad and all "keeping solutions" of > python-mad and kdemultimedia3-mad have worked correctly. > So I cannot reproduce the error. You did exactly, but maybe you don't call it an error ;-) Yes, keeping python-mad and kdemultimedia3-mad works without problems. That was one half of this bugreport and is fixed. But: These packages have unresolved dependencies which could easily be solved by _not deleting_ the mad package. Unfortunately, the solver doesn't offer this as solution and simply displays "all dependencies are OK". It seems the solver does not offer "do not delete $other_package" as solution in case $other_package is marked for deletion (by user or by 'delete unmaintained' option). See the (faked) conflicts.txt in comment #4 for an explanation what I expect - IIRC it worked this way in 10.0. BTW: This problem still exists in 10.1 final. In case you need fresh y2logs, just ask.
Ahh, I see your suggestion. Yes this would be nice, but there some internal changes in the solver required getting the additional information. In order reducing the rics of side effects I would like to make this changes after SLES. So I reduce the bug level to normal cause it would be more like an enhancement now. But I must admit an *strong* enhancement.;-) Thorsten are you agreeing ? strategy: Evalute the status DEPENDS_ON and adding the dependency to this status. 2006-05-15 12:14:55 <999> 10.10.3.222(3177) [solver] ResolverQueue.cc(processOnce):223 =====> 1st pass: [[Uninstall: I_Lu_[package]python-mad-0.5.4-6.i586 (unsatisfied dependency), Triggered By [package] (namedcap) libmad.so.0]] 2006-05-15 12:14:55 <999> 10.10.3.222(3177) [solver] QueueItemUninstall.cc(process):285 QueueItemUninstall::process(<I_Lu_>I_Lu_[package]python-mad-0.5.4-6.i586 2006-05-15 12:14:55 <999> 10.10.3.222(3177) [solver] ResolverContext.cc(addInfo):1122 ResolverContext[0xb54b9e8]::addInfo(ResolverInfo<DEPENDS_ON> python-mad-0.5.4-6.i586python-mad-0.5.4-6.i586 depended on mad-0.15.1b-1.pm.3.i586) 2006-05-15 12:14:55 <999> 10.10.3.222(3177) [solver] ResolverContext.cc(uninstall):371 ResolverContext[0xb54b9e8]::uninstall(I_Lu_[package]python-mad-0.5.4-6.i586 )context-status:I_Lu_ 2006-05-15 12:14:55 <999> 10.10.3.222(3177) [solver] ResolverContext.cc(setStatus):181 [0xb54b9e8]setStatus(I_Lu_[package]python-mad-0.5.4-6.i586, I_Ts_) 2006-05-15 12:14:55 <999> 10.10.3.222(3177) [solver] ResolverContext.cc(setStatus):185 MARK 2006-05-15 12:14:55 <999> 10.10.3.222(3177) [solver] ResolverInfo.cc(ResolverInfo):205 ResolverInfo<UNINSTALL_LOCKED> python-mad-0.5.4-6.i586 2006-05-15 12:14:55 <2> 10.10.3.222(3177) [solver] ResolverContext.cc(addError):1161 ******** Error: ResolverInfo<UNINSTALL_LOCKED> python-mad-0.5.4-6.i586 Error!>>python-mad-0.5.4-6.i586 is locked and cannot be uninstalled.<<, Trigger: none 2006-05-15 12:14:55 <2> 10.10.3.222(3177) [solver] ResolverContext.cc(addError):1161 2006-05-15 12:14:55 <999> 10.10.3.222(3177) [solver] ResolverContext.cc(addInfo):1122 ResolverContext[0xb54b9e8]::addInfo(ResolverInfo<UNINSTALL_LOCKED> python-mad-0.5.4-6.i586 Error!>>python-mad-0.5.4-6.i586 is locked and cannot be uninstalled.<<, Trigger: none 2006-05-15 12:14:55 <999> 10.10.3.222(3177) [solver] ResolverContext.cc(addInfo):1122 ) 2006-05-15 12:14:55 <999> 10.10.3.222(3177) [solver] ResolverInfo.cc(ResolverInfo):205 ResolverInfo<INVALID_SOLUTION>
Set to later after GM of SLES
(In reply to comment #17) > Set to later after GM of SLES SLES is released, so it's time to reopen ;-)
ping ;-) Any news on this? (and please don't tell me it's too late for 10.2...)
I just did a quick test on 10.2 final (I marked aaa_base for deletion ;-) and somewhere in the long dependency warning list, I see "aaa_base behalten" ("don't delete aaa_base"). Choosing this option solves all the dependency warnings - as expected. Therefore I consider this bug is fixed in 10.2 :-) Whatever you did - thanks!