So as I see it there are at least three cases here:
The install is accidentally broken. Because we've all been living without apt for so long, various inconsistencies can arise. It would indeed be a great feature if apt offered to fix the problems. Since there may be many ways of fixing things it might be best if this were handled in the front-end though. This would give the sysadmin a chance to adjust the solution. The install is broken because of unnecessary dependencies. This is the case the other person (sorry I don't keep old mail from lists) was talking about. Either the sysadmin has installed software in /usr/local or the package maintainer was overeager with dependencies. Currently the best solution is equivs. It might be nice one day to have a front-end for equivs though. The install is broken and the sysadmin doesn't want to fix it. Possibly the sysadmin actually wants a package unpacked but not configured (for example, if the configuring the package changes the systems behaviour and he just wanted the files to be available.) Or possibly the sysadmin simply doesn't want to or can't fix the problem right now (Such as when waiting for an imminent new package that will fix the problem). This last case is the case i'm concerned with. I strongly suggest APT simply refuse to handle any package that directly or indirectly depends on the unconfigured packages, but continue to work on any other packages. A related case is what happens when an error occurs downloading files. Currently it panics and doesn't upgrade anything. Ideally it should check what files have been downloaded, exclude any that can't be satisfied without the erroneous package, and handle the valid ones. For example, just today I tried to upgrade 16 packages. One wasn't in the archive, which caused the entire upgrade to fail. None of the other packages were dependant on that one package. greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
