Bugzilla – Bug 375625
forcing resolution gives different results than not-forcing even if the solution can be found without removing anything
Last modified: 2008-04-24 16:03:49 UTC
zypper install libqt4-devel gives: The following packages are going to be upgraded: libqt4-x11 libqt4-sql-sqlite libqt4-sql libqt4-qt3support libqt4-devel libqt4 libQtWebKit4 The following package is going to be REMOVED: libqt4-devel-doc the removal of libqt4-devel-doc doesn't make sense. it should be upgraded together with the other packages. libqt4-devel-doc has a versioned requires on libqt4, which is upgraded (correctly) in the proposal above. I'm not sure why it forgets about libqt4-devel-doc-data here as well.
Created attachment 205142 [details] tar.bz2 of solver testcase
hmm, libqt4-devel-doc-data is apparently forgotten because it doesn't have a versioned requires on libqt4. fixed now.
Another point in case why forceResolve is bad. Without it, you would have seen the reason why libqt4-devel-doc was going to be removed. Try: zypper install --force-resolution off libqt4-devel
$ zypper install --force-resolution off libqt4-devel Refreshing 'stable-x86' Refreshing 'devel:tools' Reading installed packages... The following packages are going to be upgraded: libqt4-devel-doc-data libqt4-x11 libqt4-sql-sqlite libqt4-sql libqt4-qt3support libqt4-devel-doc libqt4-devel libqt4 libQtWebKit4 Overall download size: 88.4 M. After the operation, additional 9.0 K will be used. Continue? [YES/no]: no it doesn't give a reason.
your bug is not reproducible and I'm afraid it wasn't even reproducible the moment you created the test case. Because with the data you have, it would have done this: >!> Solution : >!> install libQtWebKit4-4.3.93.20080325-1.i586[stable-x86] >!> install libqt4-4.3.93.20080325-1.i586[stable-x86] >!> install libqt4-devel-4.3.93.20080325-1.i586[stable-x86] >!> install libqt4-devel-doc-4.3.93.20080325-1.i586[stable-x86] >!> install libqt4-devel-doc-data-4.3.93.20080325-1.noarch[stable-x86] >!> install libqt4-qt3support-4.3.93.20080325-1.i586[stable-x86] >!> install libqt4-sql-4.3.93.20080325-1.i586[stable-x86] >!> install libqt4-sql-sqlite-4.3.93.20080325-1.i586[stable-x86] >!> install libqt4-x11-4.3.93.20080325-1.i586[stable-x86] >!> update libQtWebKit4-4.3.93.20080319-1.i586[@System] >!> update libqt4-4.3.93.20080319-1.i586[@System] >!> update libqt4-devel-4.3.93.20080319-1.i586[@System] >!> update libqt4-devel-doc-4.3.93.20080319-1.i586[@System] >!> update libqt4-devel-doc-data-4.3.93.20080319-1.noarch[@System] >!> update libqt4-qt3support-4.3.93.20080319-1.i586[@System] >!> update libqt4-sql-4.3.93.20080319-1.i586[@System] >!> update libqt4-sql-sqlite-4.3.93.20080319-1.i586[@System] >!> update libqt4-x11-4.3.93.20080319-1.i586[@System] Taking that half the packages are from stable-x86 and half from dirk:playground I guess dirk:playground wasn't in sync with stable yet and so it was broken for a millisecond. At least that's what sat solver gives: >!> upgrade libQtWebKit4-4.3.93.20080319-1.i586 => libQtWebKit4-4.3.93.20080325-1.i586[stable-x86] >!> !unflag libqt4-4.3.93.20080319-1.i586[system] >!> upgrade libqt4-4.3.93.20080319-1.i586 => libqt4-4.3.93.20080325-1.i586[stable-x86] >!> !unflag libqt4-devel-4.3.93.20080317-3.1.i586[home:dirkmueller:playground] >!> upgrade libqt4-devel-4.3.93.20080319-1.i586 => libqt4-devel-4.3.93.20080325-1.i586[stable-x86] >!> !unflag libqt4-devel-doc-4.3.93.20080319-1.i586[system] >!> upgrade libqt4-devel-doc-4.3.93.20080319-1.i586 => libqt4-devel-doc-4.3.93.20080325-1.i586[stable-x86] >!> !unflag libqt4-devel-doc-data-4.3.93.20080317-4.1.noarch[home:dirkmueller:playground] >!> upgrade libqt4-devel-doc-data-4.3.93.20080319-1.noarch => libqt4-devel-doc-data-4.3.93.20080325-1.noarch[stable-x86] >!> !unflag libqt4-qt3support-4.3.93.20080319-1.i586[system] >!> upgrade libqt4-qt3support-4.3.93.20080319-1.i586 => libqt4-qt3support-4.3.93.20080325-1.i586[stable-x86] >!> !unflag libqt4-sql-4.3.93.20080317-3.1.i586[home:dirkmueller:playground] >!> upgrade libqt4-sql-4.3.93.20080319-1.i586 => libqt4-sql-4.3.93.20080325-1.i586[stable-x86] >!> !unflag libqt4-sql-sqlite-4.3.93.20080319-1.i586[system] >!> upgrade libqt4-sql-sqlite-4.3.93.20080319-1.i586 => libqt4-sql-sqlite-4.3.93.20080325-1.i586[stable-x86] >!> !unflag libqt4-x11-4.3.93.20080317-3.1.i586[home:dirkmueller:playground] >!> upgrade libqt4-x11-4.3.93.20080319-1.i586 => libqt4-x11-4.3.93.20080325-1.i586[stable-x86] Unfortunately INVALID as it is.
I don't have home:dirkmueller:playground on autorefresh. Furthermore, there is a consistent and newest state available from stable-x86. that there are older versions also in other repositories should not matter. I guess you have either an older or a newer version of libzypp, because the behavior is perfectly reproducible here with the libzypp from stable-x86 (4.6.1-2)
ok, I have no idea how to emulate force-resolution behaviour with test cases. And the bug that zypper is using that as default is handled somewhere else afaik.
ok, found it: ~mls/sat-solver/testsuite/deptestomatic /suse/coolo/Export/tc/375625/solver-test.xml >!> remove libqt4-devel-doc-4.3.93.20080319-1.i586 Without forceResolve it works out
Why is this assigned to me?
(In reply to comment #3 from Michael Schroeder) > Another point in case why forceResolve is bad. Without it, you would have seen > the reason why libqt4-devel-doc was going to be removed. Another point where i don't agree. I (or users usually) don't care about the reason unless i really care about qt4-devel-doc being installed. I see the install summary. If i don't care about qt4-devel-doc, i say to myself "well, it was in the way for some reason, i don't care, go ahead" and that's it. If do care, i cancel and retry with the --force-resolution off to see what's up. It's *convenient*, disabling the --force-resolution would be *annoying*. If an unexperienced user comes across this and asks on a forum or bugzilla, we reply "try with --force-resoltion off" to see why. If we don't force the resolution by default, we'll get _lots_ of rants like "why do i have to decide, zypper should do it automatically". Ehm.. but i think we have made it clear to each other recently, this comment is somewhat older. @Schubi or Michael: so what's to problem in this bug after all? Why is it assigned to me? :O)
there is no install conflict, so the default of --force-resolution doesn't matter. the testcase uncovers a bug however where --force-resolution being enabled causes an incorrect behaviour of the solver. as you can see there is no error situation with --force-resolution being off. thats why coolo reassigned it to mls.
Maybe you should offer to turn off forceresolve and rerun the solver with your final 'y/n' question so that the user doesn't need to re-run the command. Regarding #11: libzypp translates forceResolve to "allowuninstall", and that's exactly what the solver does: throw away all packages that are in the way. Not really a bug in the solver. (Nevertheless, it will be fixed when I add "feature rules").
(In reply to comment #12 from Michael Schroeder) > Maybe you should offer to turn off forceresolve and rerun the solver with your > final 'y/n' question so that the user doesn't need to re-run the command. Yes, i thought about that. 'y/n/f' or something. It would be two key strokes (f,<enter>) instead of many. That sounds like it's worth doing it and polluting the y/n prompt. Maybe i'll add some heuristic there, e.g. show the additional 'f' only if the install command was used and there is at least one package scheduled for removal. > Regarding #11: libzypp translates forceResolve to "allowuninstall", and that's > exactly what the solver does: throw away all packages that are in the way. Not But were there any? Dirk suggests (c#11) there were none. > really a bug in the solver. (Nevertheless, it will be fixed when I add "feature > rules").
I'd like 'p' for "show problems" better. Regarding #11: That's because the solver tries a bit harder to make things work if forceResolve is off.
but what is there to try harder? there is no conflict or anything?
I wish Michael would accept that there is a bug without bitching about zypper's default ;(
I wish you had a clue what you're talking about.
I would like to know the answer to Dirk's question (c#15) for sure :O)
Created attachment 208524 [details] zypper install zypper (test case)
Created attachment 208526 [details] zypper install --no-force-resolve zypper [test-case]
Created attachment 208529 [details] zypper install zypper [output]
Created attachment 208530 [details] zypper install --no-force-resolve zypper [output]
Please see the attachments. I believe zypper install zypper should give the same result in this case whether you use --force-resolution or not. There are no problems which must be forced in order to get a solution. So why does it behave like this? Is it bug or not?
BTW, you can use these test cases also to debug the re-installation problem as well.
Why is this set as NEEDINFO from me? I already gave the info in #12.
Michael, can you ping me and Schubi once the feature rules are ready? Schubi, will you make libzypp's setForceResolve() use them?
I implemented them on Friday, so current SVN already has them. Nothing needs to be changed on schubi's side, the flag is still "allowuninstall". It just doesn't uninstall so much anymore ;-)
So I set it to fixed