Bug 152722

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 jkeating 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 ncrawfor.mil 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 jkeating 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 ncrawfor.mil 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 
smtpdaemon...

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 ?
    yummain.main(sys.argv[1:])
  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
yum-1.0.3-1_80
# rpm -q rpm
rpm-4.1.1-1.8x

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 ncrawfor.mil 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 
with?)
# 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,
-Nick



------- Bug moved to this database by dkl 2005-03-30 18:25 -------

This bug previously known as bug 1628 at https://bugzilla.fedora.us/
https://bugzilla.fedora.us/show_bug.cgi?id=1628
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.