Bug 375625

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