Description of problem: upgraded from an up to date F7 system. now sendmail is the F7 version but libdb is the F8 version and sendmail cannot start because it wants libdb 4.5, not 4.6. Version-Release number of selected component (if applicable): sendmail-8.14.1-4.2.fc7 db4-4.6.18-2.fc8 Additional info: sendmail isn't alone here. there's still 128 fc7 rpms on my system. this kind of thing caused nasty problems going from fc6 to f7. i realise it's not the fact they're "fc7" that's the problem - it's dependencies that cause the trouble. sendmail-8.14.1-4.2.fc8 is available and yum appears to be happy to install it, so i guess that's fixing this problem. however, i think the issue still needs to be fixed. surely it'd be quite easy to automatically scan for dependency issues like this - at least before each release? this kind of thing is a bit embarrassing to explain to new users on IRC! ;-)
sendmail-8.14.1-4.2.fc8 is part of FC-8, therefore it seems that your update is incomplete. This is not a sendmail problem. How did you update? By hand or with anaconda?
pxe-booted anaconda nfs upgrade. indeed, 8.14.1-4.2.fc8 is part of FC-8 now. but an up to date F7 currently includes 8.14.1-4.2.fc7 whereas the F8T2 dvd contains 8.14.1-4.1.fc8. i guess that's why sendmail (and the other 127 packages) didn't update during the upgrade. like i said, i've had many similar problems going from FC6 to F7 - the updated FC6 system has more recent version numbers than the packages available in F7. mostly, but not exclusively, that happened with java things. e.g. i couldn't install eclipse until i'd forced rpm to remove a lot of stuff. i think the question here is: why did anaconda upgrade db4 when it didn't upgrade sendmail? not upgrading sendmail seems like the right thing to do (because of the version numbers) but then it should also refuse to upgrade db4 (because of dependencies).
one weird thing there is that sendmail-8.14.1-4.2 in F7 depends on db4-4.5 whereas the exact same version of sendmail (and the previous version too) in F8 depends on db4-4.6. maybe that's the root of the problem.
This is not a sendmail bug. Assigning to anaconda.
If we don't upgrade db4, though, then the entire chain of what wants upgrading has to be stopped and you end up being unable to upgrade _anything_ really. After an upgrade, you really need to run 'yum update' to pull in anything newer. Although at release time, we should also ensure that upgrade paths are clean.
surely, this is still broken. updates to sendmail (and other things) go into both F7 updates and F8 updates. if you're fully up to date in F7 then you don't get a new sendmail (with its new db4 dependency) even if you do a yum update. if those really are identical versions then surely the dependency on db4 should be "4.5 or greater" in both the F7 and the F8 version? if they're not identical then surely they should have different version numbers? and if the F7/F8 thing counts as a different version number then anaconda/yum should upgrade to the F8 version. possibly there's an ownership problem here - is this a problem in sendmail, packagers, anaconda, yum or is it some issue that falls between them all? i think i've got a bug open somewhere along the lines of "at release time, we should also ensure..." suggesting that that really ought to be an automated process. i'll see if i can find that and reference it here. regarding "at release time, we should..." can you have a look at my bug 232212 and see if you can answer my question at the end there? perhaps that might also solve any ownership issue on this problem too.
one day i'll learn not to hit 'save' too soon. ignore the "i think i've got a bug open..." paragraph above - the final paragraph was meant to replace it. :-/
db4 is still going to get upgraded unless some package requires a specific version of it, in which case you are going to end up with a bunch of packages that don't get upgraded as all the other things that depend on db4 get stuck. This really isn't anything we can fix in anaconda - it's just how the dependencies work out.