On 17 Jun 2002, seth vidal wrote: > kdesdk is one I can't fix easily. Red Hat's kde maintainer failed to > obsoleted kdesdk-devel when he split the package into 40 different > subpackages. > > the sendmail-smrsh I understand, sorta, we split the sendmail-smrsh > package off from the main sendmail and the main sendmail knows nothing > about it. Since in the dulug distro we don't officially support in-place > upgrades b/t versions I'm not going to fix this. > > This is the situation in yum/yup/apt/anything breaks down. If the > packages explicitly conflict and one is not obviously newer than the > other then you're screwed. > > We never noticed that in the tests I did b/c they were all machines > running postfix. Stop using sendmail :) I have, actually. I just haven't EVERYWHERE yet, and the machine in question isn't an active mailhost. sendmail is a tolerable MTA. I'll start converting my home clients to postfix. My home server/gateway too, but it needs a massive update anyway -- it is probably a couple of revisions behind. With yum I'm hoping to be able to keep my servers a bit more current, since rebuilding them after a major upgrade is a real PITA. > > Are cases like these automatable? In just about every case, "doing the > > right thing" is going to be --erasing the old packages until yum is > > happy installing the new packages. The way things look now, I'll have > > to do this by hand, a package at a time (which makes me nervous -- > > erasing packages before I know that yum is going to eventually get > > through the update:-). > > > its just the ones that are KNOWN conflicts. Icon and I have encountered > most, if not all, of them. > > kdesdk-devel is one of those. > > again its not a situation we can deal with. Its an explicit conflict > caused by sloppy packaging. > > so far the ones I've encountered include: > kdesdk-devel > sendmail-smrsh > kernel < 2.4.7 conflicting with mkinitrd. There is one concept of "newness" that one can use to fuel the decision(s). In a whole lot of cases, the packages coming from the named target/server directory will be presumed to supercede anything on the system. In fact, I'd argue that this is what you'd LIKE to at least be ABLE to make the default behavior. If I were doing a full reinstall to upgrade, that is what would happen, for example, so it would be just groovy to be able to force it to happen with a specific command line option. Something like yum upgrade instead of yum update and then just have it internally "obsolete" any already installed, conflicted packages (whatever the source) in favor of the ones in the upgrade server/path. That way yum could actually repair minor damage and stupidity on the part of the packagers by doing pretty much what you'd expect to have happen on a full reinstall upgrade, but without trashing all those lovely configuration files or rebuilding your filesystem. 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
