On 18 Jun 2002, seth vidal wrote: > Also - "Stream of messages"? In your case its a stream b/c you've > installed a fair bit of bizarre crap. "most users" won't have done that > to their systems. KDE (lots of KDE, hence the term "stream") and sendmail? Those are the only conflicts I see, and are hardly bizarre, although sendmail is arguably deprecated in favor of postfix. I just completely reinstalled the system clean to 7.2 about oh, two months ago. Having run sendmail for some 18 years now, though, it isn't an insane choice, just an inseth one...;-) > The problem with "automagic" is that it is not. It frequently breaks > things. > > What I _should_ be able to do is catch the conflict errors and suggest a > course of action for the user. To remove/ignore them automatically will > cause a lot of pain, I can think that the "you overwrote my ___________" > emails will be MUCH worse to deal with than the "it doesn't resolve my > broken package conflict" emails. > > One way to deal with it would be to prompt the user with the default > being to mark the older pkg to be erased and rerun the dependency > resolution. > > It would take longer for the user but its possible. Longer for the user? I'm not a complete novice (a complete idiot, perhaps, but definitely not a novice:-) and I can't see any clean/fun/fast way of fixing just the KDE/Sendmail problem so that yum can proceed to do its thing. I cannot just MARK the packages to be erased and rerun the dependency resolution to be sure that everything is ok at the end -- I have to actually erase the packages. Which are likely in the dependency list of a few million other packages, so I have to erase them too, and then reinstall everything. Or I can force an update, but that's the way things get broken because one can't iterate the erase/dependency check to consistency beforehand. Is there some simple way to fix this that I'm ignorant of EXCEPT to do it inside a yum-like tool that can do the requisite marking and dependency resolution all at one time before proceeding? > I'm not sure I'm terribly happy with this, though. That would be a tolerable approach, but what does Red Hat do when one selects the "upgrade" option in a 7.3 reinstall? It does the wrong thing in some ways (trashing and rebuilding the base filesystem, trashing key configuration files) but it does the right thing as far as package selection. In fact, I'd say that this "defines" the right thing for yum to do if one enters a newly defined "yum upgrade". After all, users expect (or should expect and should be told to expect in the man pages) things to be overwritten and possibly broken in an upgrade, but not in an update. If all yum breaks are at MOST obscure packages that weren't installed via a standard RH plus yum/yup install/update sequence, well, that's pretty darned good. Breaking RH-installed, yup-maintained sendmail or kde would be bad, of course, but I think that this sort of conflict is resolvable just the way you suggest above -- marking the already installed (older or not!) package to be erased and replaced with the corresponding package in the new, specified distribution tree and then giving the user a choice to accept the action and be left with a decently usable system when done (but maybe have to reinstall a few packages) or not accept the action and maybe be left with a pile of crap when done. By defaulting to the current/specified distribution tree on an "upgrade" update one could even use it to back off of a lot of garbage to a "clean" site-based release (while of course logging the packages that it couldn't find or deal with). In fact, one could use it as a "downgrade" -- go as cleanly as possible back to 7.2 from 7.3, for example! I could see this being very useful to a person testing a bunch of new RPM's or a new full distribution, or to people seeking to do a deep upgrade of an old system without losing a basic configuration -- that is, to me;-). Probably to you too, though. rgb Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx
