Bugzilla – Bug 548017
conflict in zypper dup (gwenhywfar2), but this package can be zypper install'ed
Last modified: 2010-10-18 20:12:39 UTC
# zypper dup Loading repository data... Reading installed packages... Computing distribution upgrade... Problem: gwenhywfar38-2.6.2-2.3.x86_64 requires gwenhywfar2 >= 2.6.2, but this requirement cannot be provided uninstallable providers: gwenhywfar2-2.6.2-2.3.i586[11.2-oss] gwenhywfar2-2.6.2-2.3.x86_64[11.2-oss] Solution 1: deinstallation of gwenhywfar-3.8.3-3.13.x86_64 Solution 2: keep gwenhywfar38-2.6.2-1.16.x86_64 Solution 3: break gwenhywfar38 by ignoring some of its dependencies The interesting thing is that gwenhywfar2 2.6.2 is available and installable: # zypper in gwenhywfar2 Loading repository data... Reading installed packages... Resolving package dependencies... The following NEW packages are going to be installed: gwenhywfar2 gwenhywfar3 gwenhywfar3-lang libgwenhywfar3-47 The following packages are going to be REMOVED: gwenhywfar gwenhywfar47 libgwenhywfar47 The following package is going to be upgraded: gwenhywfar38 1 package to upgrade, 4 new, 3 to remove. Overall download size: 835.0 KiB. After the operation, additional 637.0 KiB will be used. I wonder why zypper dup reports a conflict here while zypper in can (and does) solve it itsself.
Created attachment 323001 [details] zypper log and solver testcase
That's because 'zypper in' sets forceResolution to true and I can't convince the zypper author to change that. It will also complain if you use 'zypper in -R'. (forceResolution basically says that it's ok to deinstall packages, that's what happens here: it deinstalls gwenhywfar. Zypper dup wants you to confirm it, see solution 1)
(In reply to comment #2) > That's because 'zypper in' sets forceResolution to true and I can't convince > the zypper author to change that. Well, this is nice example why forceResolution is good :O) Would you really want the solver problem dialog instead of the solution above? > It will also complain if you use 'zypper in -R'. > > (forceResolution basically says that it's ok to deinstall packages, that's what > happens here: it deinstalls gwenhywfar. Zypper dup wants you to confirm it, see > solution 1)
Yes of course. For two reasons: 1) maybe there are multiple possibilities to solve the problem and I want to choose one, and 2) if I look at the list of packages that are going to be removed I have no clue if that's ok (because it's just a package rename and I still have the functionality) or bad (it's just deinstalled because of the forceResolution).
I'd also favor a default without force. Not just because I'd like to be asked, but also because I'd like zypper to behave consistently. If having to write -f annoys, zypper.conf could offer setting default options for commands: in_default = -f Maybe we should vote on zypp-devel.
c#5: It's not -f, it's --force-resolution. But there's mostly no point in writing that to the command line - you just do 'zypper in' and if there's a problem you just choose solution in the dialog. Writing --force-resolution would make sense if the problems were too many and you want to try let the solver remove the problematic packages. ---------- I have no problem changing the default to --no-force-resolution, but frankly guys so far i have not heard a good reason. To c#4: you can always enter 'p' at the 'Continue?' prompt to run the solver again with forceResoltuion off - when you're happy with the result, you just go on and install/remove; if you're not, you enter 'p' and you get the solver dialog. (the 'p' option should also appear next to y/n as y/n/p, in case the 'install' command also removes packages). But i'm curious whether making this the default will make users happier, so let's try it :O) I don't know about the voting, we can try it. Can one of you guys send a mail explaining this? Just to make sure: we don't want to change the default for 'remove' right?
Yes, remove has to use forceResolve, otherwise people would get really unhappy ;-)
(maybe it would be enough if renamed packages wouldn't be listed as "REMOVED", so that I know that 'p' is useful when a package shows up as removed)
(BTW, showing the 'p' option had bug 549183. fixed now) c#8: if we can reliably determine which package was renamed, we can add such 'section' to the summary. But i have a feeling this is not that easy. BTW, is there anything left to solve in this report? If not, we can close it and move the forceResolution and other discussions to the mailing list(s).
(In reply to comment #9) > c#8: if we can reliably determine which package was renamed, we can add such > 'section' to the summary. But i have a feeling this is not that easy. I have no idea how this can be handled technically inside zypp, but the data is easily available ;-) Name the section "obsolete packages" and list packages that are obsoleted by some other package in this section. I guess most of them were renamed. Even if a package is obsoleted for some other reason, its replacement will (hopefully) offer the same functionality. (If you want to do it perfect, keep a list with "obsoleted by" for the detailed view.)
That looks like a good idea, but for later. I'll add it to zypper's TODO list. As for the original problem, since zypper 1.1.12 one can configure zypper to use force-resolution with specified commands in zypper.conf, and the default is: forceResolution = remove so i'll close this report.