Red Hat Bugzilla – Bug 310611
sendmail can't start due to wrong libdb version after upgrade from F7
Last modified: 2008-10-09 15:54:04 EDT
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 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
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.