Bug 231296

the same problems alreay existed in 10.1 -- now I got bitten again when updating my main server from 10.0 to 10.2 using retail DVD9:

the 10.0 system had 2460 RPMs installed, the updated 10.2 system right now has 2814 RPMs (rpm -qa | wc -l), so it's a larger system with quite a number of non-SUSE packages (e.g. mplayer/dvdauthor/transcode/... from packman). also I told  yast not to delete old and now unsupported packages (e.g. I still need and use xephem and other "legacy" packages).

the server is a 2.4 GHz P4 with 1 GB ram and 3ware hw raid, so reasonably performant.

BUT it took 1.5+ hours real time (and 38 cpu-minutes for y2base !!!) to handle the  packakge conflicts before the real update could be started -- that really sucked :-(



I see 2+ problems for this process since 10.1:

1) a single run to check dependancies takes about ~40-60 seconds which IMHO is quite much for 2.4 GHz with enough ram.

2) only one package conflict is displayed at one time. so for every single old/locked/non-suse package I have to check dependancies again summing up to 38 CPU-minutes!

up to 10.0 all conflicts had been displayed at once in a long list, so it was possible to resolve many problems (or "keep" locked RPMs) in one run, so only very few check cycles have been needed

3) I explicitly selected that yast shall not delete unsupported RPMs, but non-suse RPMs like MPlayer/transcode/dvdauthor and others have been put to state "auto-delete" -- why ???

so I had to set those RPMs to "lock" to keep them, which then caused conflicked (why????) which I had to "resolve" by "keep"ing all those RPMs, one at a time.


4) compared to the topics above a minor nitpick, but still nasty and quite time-consuming:

some packages like "cdrecord/ethereal/..." showed up in the "auto-delete" list (in combination with mplayer etc., see above).   I know that I still want to keep those tools, so my decission was to lock them too, because there was no information that those RPMs have been renamed.

only after a dependancy check I got told that cdrecord rpm is now spelled "wodim", and ethereal is now spelled wireshark -- again consuming zillions of CPU cycles for many single tests of such renamed RPMs...

this problem would not show up if I could trust the auto-delete list. but since there have been many "real-false" entries in this list, I had to dig out some of those reasonable renames too.  


summing up, the package selection (only because of the conflict stuff) was a _real_ PITA in both 10.1 and 10.2 -- this was _much_ better up to 10.0.
this is esp. pitty since the new package selection and schema stuff in yast really improved much.

for SUSE users who update their systems (no new install for every version) I consider this a _major_ update problem!


I've kept a copy of the old 10.0 /var/lib/rpm/ and during update y2base I created and saved that "solverTestcase" stuff (/var/log/YaST2/solverTestcase/y2log is 360 MB, y2log.tgz is 19 MB!) in case you need data to figure out what's going slow and wrong here.
solverTestcase