When attempting to apply a YUM update to a RedHat 8.0 box the most recent
Legacy mutt package causes the installation to abort. The message given is:
.package mutt needs smtpdaemon (not provided)
This is halting the application of other patches/packages from the Legacy
repository, the only available work around is to apply non-impacted packages
by hand. (I run YUM for automated patch pushes to 250 RedHat 8.0 machines,
this work around isn't viable for me :( ).
------- Additional Comments From firstname.lastname@example.org 2004-05-20 13:17:10 ----
Package sendmail and postfix (all the way back to originally shipped from RH)
provide this virtual dep. Is there some reason why your yum is ignoring
sendmail or postfix ?
------- Additional Comments From email@example.com 2004-05-20 13:39:25 ----
I apologize for the invalid bug, I'm still trying to work the issue.
The issue has occurred on all RH 8.0 machines I manage, they all ran `up2date -
u` nightly until the RH EOL, then migrated to YUM on Legacy.
It appears as though the machines all believe they don't have postfix
installed, and `rpm -q --whatprovies smtpdaemon` returns nothing.
As they've lived on nothing but up2date and YUM, and have various
install/patch points and all are acting the same, I assumed it was an issue
with the RPM package. I'm sorry.
I do greatly apologize for the wasted time.
------- Additional Comments From firstname.lastname@example.org 2004-05-20 13:44:31 ----
It's not a total waste of time. If they don't have neither sendmail nor postfix
installed, yum should have pulled them in as a dep. If you manually run yum
update mutt, does it resolve out sendmail or postfix as a dep? Perhaps yum is
confused by the virtual depends being satisfied by either postfix or sendmail.
Adding Seth Vidal to the bug report for his input (bug may have to be moved to
Yum's official bugzilla).
------- Additional Comments From email@example.com 2004-05-20 14:04:35 ----
Looks as though I have a sweeping RPM DB problem.
I know for a fact all machines have both sendmail and postfix installed,
postfix isn't showing up in `rpm -q`, the virtual dep isn't being matched even
though sendmail IS showing up and `rpm -q --provides sendmail` even shows
I did an rpmdb --rebuilddb on a few after kicking off the users, which fixed
the rpm issues, `rpm -q --whatprovides smtpdaemon` returns what it should
now... but now YUM blew up on me with;
# yum update mutt
rpmdb: /var/lib/rpm/Packages: unsupported hash version: 8
error: cannot open Packages index using db3 - Invalid argument (22)
Traceback (most recent call last):
File "/usr/bin/yum", line 44, in ?
File "yummain.py", line 101, in main
File "yummain.py", line 58, in parseCmdArgs
File "config.py", line 120, in __init__
File "config.py", line 169, in _getsysver
File "clientStuff.py", line 164, in openrpmdb
NameError: global name 'RpmError' is not defined
# rpm -q yum
# rpm -q rpm
Very strange. I've just run a full yum update on a brand new RH 8 load
begging to end and everything went perfect.
Now I've got to figure out how all these machines suffered corruption around
the same issue.
Again, sorry for involving you all based on an assumption, looks like a
problem unique to something going on here (working with 6 other SysAdm's I
can't say for certain what all has happened to these machines over time).
------- Additional Comments From firstname.lastname@example.org 2004-05-20 14:34:20 ----
Seem to have found a fix;
# rpmdb --rebuilddb (updates the database to a format yum 1.0.3 can't deal
# rpm -Uvh http://www.linux.duke.edu/projects/yum/download/2.0/yum-2.0.7-
1.noarch.rpm (to deal with the new database format?)
# yum update
And after further investigation it wasn't as broad a problem as I first
though. Out of all the emails I got I read the top 10 and the last 2. Many
of the updates in the middle went fine.
Thanks for all the help,
------- Bug moved to this database by email@example.com 2005-03-30 18:25 -------
This bug previously known as bug 1628 at https://bugzilla.fedora.us/
Originally filed under the Fedora Legacy product and General component.
Unknown priority P2. Setting to default priority "normal".
Unknown platform PC. Setting to default platform "All".
Unknown severity critical. Setting to default severity "normal".
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.