On 17 Jun 2002, seth vidal wrote: > lets see if I can phrase this the best way: > > no. I don't understand this. Could you repeat it a different way? ;-) > I will not start doing depedency "intelligence" outside of rpm in yum. > > > if rpm doesn't give me the information, I'm not going to create and > entire legacy class by "rethinking" what rpm does. The solution to poor > packaging is not "write a new concept of what is _really_ newer" its fix > the packaging/packagers. Right. So instead of providing a (possibly kludgy) fix that IS under your control, you're going to wait for a diverse group of humans scattered to the winds to alter their behavior? What century do you expect this to occur in, again? I also have to disagree with your premise. As I said, if I (as an installer) CHOOSE the upgrade option, I'm basically directing the tool to reinstall the system from a specified rpm base. It would be perfectly reasonable to totally ignore old dependency information and do a clean reinstall of all installed packages (or better, all packages that overlap or contain installed files). That would confine dependency checking to only the new tree, where it belongs. If the new tree is screwed up, well, that IS under your control and can at least be fixed in just one place. I'll also state unambiguously -- many (most?) of the future users of yum will not be able to cope with the stream of messages indicating conflicted dependencies on an upgrade. If it ain't automagic for them, it's broke. They won't care about who screwed up or why it isn't working, they'll just consider the tool broken and will drop it. 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
