On Tue 01 Jul 2003 14:53, Gary Walsh posted as excerpted below: > Ryan T. Sammartino <[EMAIL PROTECTED]> writes: > >For the last, oh, two months or so, I have been completely unable to do > >urpmi --auto-select" due to many and various missing or out-of-date > >dependencies. > > I have the same problem, see the thread "Can't use urpmi --auto-select". > My partial solution was to use the --test option which allowed me to > get the list of packages that needed updating. Then I painstakingly > tried to install each one one at a time. This narrowed down the list of > packages that won't install. The main dependency culprits seem to be > gcc and python. Trying to upgrade these two or any packages that depend > on them, results in urpmi wanting to uninstall a large number of > packages. My most annoying problem now is that Mozilla-mail is unable > to open a compose window, so I cannot create mail or respond to received > mail. I have to use the Mozilla installed on my laptop to send mail. > My guess is that an upgrade to XFree86 might be the cause of that > problem, but I don't know. I may have to start over with a complete > reinstall of 9.1 if nothing happens to fix this soon.
I understand those creating mdk rpm packages can't do this, and that's a fair portion of the regulars on this list, but here, I always use --allow-force and --noclean. Normally, it then asks if you want to proceed anyway and will then force installation w/o uninstalling anything, but at one point some possibly still uncorrected bugs in the new rpm had it entirely uninstall ALL my KDE. Thus, be careful, but that goes with using Cooker anyway, as it's non-production grade alpha/beta level. The noclean means they stay around in the cache if anything goes wrong and the installation aborts or I answer no to some question or other, so I don't have to red/l them if I try again. Of course, that also means I have to manually clean the cache when everything installs properly. Having the cached packages around after a failed install session also allows me to try each one singly, at least if it gets to the d/l b4 failing. One of the features I've requested is the ability to tell it to go d/l them anyway, with a d/l only option, so if it doesn't get to the d/l, they are still there and I can try that without going to get them manually. Doing the trial and error single package at a time thing usually works, then, for most of them, sometimes all of them, if it was just a particularly complicated dependency that Cooker couldn't figure out, leaving only one or two sub-dependency trees that won't install. By then, I can usually figure out which package is the problem, and more intelligently decide if I want to attempt a force install on it or not. Often, force-installing one will fix the problems on several others even if they didn't seem to be directly related b4. Some weeks ago, this was the case with perl-base IIRC, for example, which once force installed allowed everything else to install without issue. And.. yes, force installing could conceivably create a rather screwed up system, but hey, this is cooker, and I shouldn't be running it on a box that can't afford to be screwed up anyway, so the risk isn't really that bad since I've already chosen to run Cooker on it. -- Duncan - List replies preferred. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." Benjamin Franklin
