Bug 404770

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.