Bugzilla – Bug 157025
Dependency resolution is sloooow
Last modified: 2006-08-22 15:49:18 UTC
When I tried to update a dual Opteron box with 4G of RAM to FACTORY, and added stable daily autotest as an additional installation source, the dependency resolver sometimes took several minutes to complete and the y2base process grew above 500MB. While the resolver was running, the GUI wasn't updated and besides the "busy" mouse cursor there was no indication that the system is still doing something useful. The inocent might think at this point that the system is frozen or has been trapped in an endless loop.
Please attach the yast logs, they might provide useful information.
I don't think I have them anymore, because later the installation was aborted for a different reason, and when I restated it, I didn't add a second source of installation.
This will be hard to debug then, can you try to reproduce this somehow?
Let's ask the maintainer directly, which additional details he needs.
First of all make a dump of your current rpm-DB. Described here: http://svn.suse.de/trac/zypp/wiki/Testing/DumpRpmDb Additional I need the complete /var/log/YaST Thank you !
I can give you those informations, but I am not sure they will be helpful, because the update attempt where I saw the slowness was later interrupted, so the logs probably didn't make it to /var/log/YaST, and the RPM database isn't the same anymore, because I made a successful update with a single installation source afterwards. So, do you want the requested data anyways? Or would it be better that I show you on a test system what I did when it happened, so that we can see if it is reproducable or not?
The existing logfiles seems to be useless, as you have already mentioned. Well, plaese try to reproduce it. But make the rpm dump before. If you cannot reproduce the bug, close this bug, cause I have no chance to solve it.
Created attachment 73059 [details] XML dump of my RPM database
Created attachment 73074 [details] YaST2 logs of the installation attempt
I've also tried to attach the descr subtrees of the two installation sources, as you told me, but each of them is >8MB, and Bugzilla has an attachment size limit of 5MB. You can find them under ~max/Export/source[12]-descr.tar.gz . Please let me know when you don't need them anymore, so that I can delete them from my home directory.
Cause I had only one bug entry of this kind and the volume of the package data is not realy "usual" I will reduce the importance. But I will have consider this. I promise this. ;-)
Schubi, what's the current status of this? Can you provide an update?
Meanwhile I have not gotten any further error from other persons concerning this bug. But it is still interesting, how long the solver takes with the double amount of packages, selections.... as normal used.
It seems that is the same bug *** This bug has been marked as a duplicate of bug 191983 ***
I haven't compared them in detail, but I think normally the newer one of a pair of duplicates is closed, and the older one stays open until it is fixed - and bug 191983 is about four months "younger" than this one.
Hm, but not if the newer bug explain WHY there is problem and which solution is available. ;-)