Bugzilla – Bug 404770
Cancel a long running dependency resolution try in package manager
Last modified: 2016-11-08 14:10:42 UTC
I would like to perform another online update by the corresponding YaST control centre module. I have tried to mark the software component "kdebase3-runtime 3.5.9-93.5" for an update. Unfortunately, the SAT solver of the new package manager is running for ages in its attempt to find a suitable installation combination to fit into the current dependency hell. (It can run for half an hour or several hours with other packages). There might be situations where this tool will never complete the requested dependency resolution in a reasonable time frame. http://en.opensuse.org/Package_Management/Sat_Solver A nasty side effect for this long running operation is that the graphical user interface is completely blocked. The contents of the application window are not refreshed. I can only abort the whole process if the searching takes too long for me. The effect after a restart is of course that a detailed installation selection must be repeated. Therefore I would prefer to cancel the request to revoke the change. The tried update can a bit delayed into the near future.
It should always finish in a couple of seconds. Can you please attach a solver testcase?
Not yet because of a system limit. - "Local file uploads must not exceed 10 MB in size."
You mean as attachment in bugzilla? Can't you make it available somewhere else and just tell us the url?
Created attachment 227078 [details] testcase Does this package contain enough informations to look further into my issue? (I hope that you will receive the complete archive by a mail.)
Yep, it contains a solver testcase containing your repository data. Some things that caught my eye: - you have a mix of 10.3 and 11.0 repositories. This is probably not really useful - the testcase contains many file locks. I don't know if they are from /etc/zypp/locks or /var/lib/zypp/SoftLocks, though. - still, running the solver to install a package like "koffice-wordprocessing" takes under a second. What do I have to do to get such a long run that you experience? To make sure that it isn't just the UI that slows things down, how does zypper behave? Is it also so slow?
(In reply to comment #5 from Michael Schroeder) > - you have a mix of 10.3 and 11.0 repositories. I have got the impression that such a setup is required during software migration. I adjusted the installation sources with priorities. > This is probably not really useful I need them both to resolve dependencies. It will be a challenge for "boolean satisfiability problems" like it can be seen from the issue "Dependency hell between Perl 5.8 and 5.10" (bug #403308). http://en.wikipedia.org/wiki/Boolean_satisfiability_problem#Runtime_behavior > - the testcase contains many file locks. Can you clarify the locking? Can items become locked if I choose the option "Do not install update" in a GUI inquiry? > What do I have to do to get such a long run that you experience? How will your test environment react to my "kdebase3..." component situation? > To make sure that it isn't just the UI that slows things down, I do not see that the graphical user interface adds hiccups during the SAT resolution process. > how does zypper behave? Is it also so slow? I do not know. I do not dare an update by the command line tool at the moment. I need (GUI) interactivity to handle the deep dependency chains/networks properly.
(In reply to comment #5 from Michael Schroeder) > - the testcase contains many file locks. Do you mean the list that is shown by the command "zypper locks"? > - still, running the solver to install a package like "koffice-wordprocessing" > takes under a second. A command like "zypper update -t package Vuze-console Vuze oxygen-icon-theme oxygen-icon-theme-scalable wine" is also instantly executed on my system. There are a few places where the process will take longer for the conflict resolution.
(In reply to comment #5 from Michael Schroeder) > What do I have to do to get such a long run that you experience? How will your test environment react if any additional installation source would be accidentally forgotten or deactivated during an update/upgrade from openSUSE 10.x to 11.x? http://en.opensuse.org/Package_Repositories#Official_Repositories
Yep, the 'zypper locks' list. So you're saying that 'zypper' is still fast? So it's not the solver, but the UI code that doesn't scale well? Regarding migration: I don't think the old repos are really needed, but they shouldn't hurt anyway (in theory).
(In reply to comment #9 from Michael Schroeder) > So you're saying that 'zypper' is still fast? I noticed that this command line tool can also result in "hiccups" like I have described it in the issue "Check responsiveness for zypper" (bug #410627). > Regarding migration: I don't think the old repos are really needed, but they > shouldn't hurt anyway (in theory). I imagine that previous repositories provide older software releases that are not provided by current repositories. I am affected by the usual dependency hell where I can not update all software components on my own to the current release.
Created attachment 228902 [details] excerpt from a screenshot I was surprised by the patch list today because it was much shorter previously. It has got entries for software components like "xen" and "poppler" where I get remarkable response times because of conflict/dependency resolution if I mark them for an update.
(In reply to comment #9 from Michael Schroeder) > So it's not the solver, but the UI code that doesn't scale well? Would you like to compare any response times for the following update candidates that will be offered by the graphical and command line user interface? Sonne:~ # zypper patch-check Downloading repository 'Packman 11.0' metadata [done] Building repository 'Packman 11.0' cache [done] Downloading repository 'Packman 10.3' metadata [done] Building repository 'Packman 10.3' cache [done] Reading installed packages... 224 patches needed (135 security patches)
Created attachment 228907 [details] result from the command "zypper patches" I would also be interested to know how to retrieve detailed dependencies from the update candicates that can not be satisfied on my systen at the moment.
The graphical user interface can guide better through the consequences and solutions presentation than the current interactive text console interface for a command like "zypper update --type package kernel*".
I have also seen an issue of this when resolving X86-64 and i586 dependencies. The UI would lock and would not respond leaving the thread cpu utilization very high. The only thing I could do is select the other package and upgrade/downgrade as needed then change the package that would cause the freeze.
As it was for openSUSE 11.0 I will close it because it is a not maintained version.