View Issue Details

IDProjectCategoryView StatusLast Update
0003613CentOS-5yumpublic2010-01-26 15:49
Reportertoracat 
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionopen 
Product Version 
Target VersionFixed in Version5.4 
Summary0003613: latest package "file" causes yum error
Description"yum update" may produce the following error if file-4.17-15.el5_3.1 is included in the update package list.

--> Processing Dependency: /usr/share/magic.mime for package: httpd
--> Finished Dependency Resolution
httpd-2.2.3-22.el5.centos.x86_64 from installed has depsolving problems
 --> Missing Dependency: /usr/share/magic.mime is needed by package
httpd-2.2.3-22.el5.centos.x86_64 (installed)
--> Running transaction check
---> Package kernel.x86_64 0:2.6.18-92.1.17.el5.centos.plus set to be erased
---> Package kernel-devel.x86_64 0:2.6.18-92.1.18.el5 set to be erased
---> Package kernel-xen-devel.x86_64 0:2.6.18-92.1.17.el5 set to be erased
--> Processing Dependency: /usr/share/magic.mime for package: httpd
--> Finished Dependency Resolution
httpd-2.2.3-22.el5.centos.x86_64 from installed has depsolving problems
 --> Missing Dependency: /usr/share/magic.mime is needed by package
httpd-2.2.3-22.el5.centos.x86_64 (installed)
Error: Missing Dependency: /usr/share/magic.mime is needed by package
httpd-2.2.3-22.el5.centos.x86_64 (installed)
Additional Information"yum clean all" solves the issue.

This does not happen on all systems. There are reported cases from multiple users:

http://www.centos.org/modules/newbb/viewtopic.php?topic_id=20191&forum=37

I have two seemingly identical systems and saw this error on only one of them.
TagsNo tags attached.

Relationships

has duplicate 0003746 closedkbsingh@karan.org Depsolve-error on upgrade because of magic.mime 
has duplicate 0003762 closedkbsingh@karan.org Python package dependency problems 

Activities

st_gotbugs

st_gotbugs

2009-05-10 13:23

reporter   ~0009333

Also saw this problem with updating file, but only on x86_64 systems.

The i386 systems updated file without issue.

yum clean all did not resolve the problem yesterday, but it does today. Very odd.

Only significant changes since yesterday were that the local mirrors have been updated and the problem systems were rebooted, but they were already running the new kernel-2.6.18-128.1.10.el5.
mharris

mharris

2009-05-11 06:00

reporter   ~0009339

I've encountered this on CentOS 5/i386 yesterday during a "yum -y update" that had about 12 packages altogether including "file". So I updated everything else individually, then tried to update 'file' again and got the same error. Tried several times in case it was a race condition or something, but to no avail.

I ended up using "yumdownloader" to download the rpm, and then upgraded it with "rpm -Uvh file*.rpm" successfully. I did not see any errors when doing the upgrade with rpm, so this does appear to be a glitch on the yum side of things.

Running a 'yum clean all' now anyway as recommended aboove, just to keep things tidy.
iddover

iddover

2009-05-11 06:26

reporter   ~0009340

Same happens to me in 2 DEll 1950 w centos 5.3 the "yum clean all" command solves the thing...
range

range

2009-05-11 12:46

administrator   ~0009341

More strangeness abounds:

root@jumper:~# yum whatprovides /usr/share/magic.mime
[...]
file-4.17-15.i386 : Ein Dienstprogramm zur Bestimmung von Dateitypen.
Matched from:
Filename : /usr/share/magic.mime

kpartx-0.4.7-23.el5_3.2.i386 : Partitions-Gerätemanager für Device-Mapper-Geräte.
Matched from:
Filename : /usr/share/magic.mime

file-4.17-15.i386 : Ein Dienstprogramm zur Bestimmung von Dateitypen.
Matched from:
Other : Provides-match: /usr/share/magic.mime

root@jumper:~# yum clean all
Loaded plugins: fastestmirror
Cleaning up Everything
Cleaning up list of fastest mirrors
root@jumper:~# yum whatprovides /usr/share/magic.mime
[...]
file-4.17-15.i386 : Ein Dienstprogramm zur Bestimmung von Dateitypen.
Matched from:
Filename : /usr/share/magic.mime

file-4.17-15.el5_3.1.i386 : Ein Dienstprogramm zur Bestimmung von Dateitypen.
Matched from:
Filename : /usr/share/magic.mime

file-4.17-15.i386 : Ein Dienstprogramm zur Bestimmung von Dateitypen.
Matched from:
Other : Provides-match: /usr/share/magic.mime


Why does yum tell me that kpartx provides /usr/share/magic.mime? Why doesn't it do that anymore after I ran yum clean all? On #centos someone had kernel-PAE in the list shown by "yum whatprovides /usr/share/magic.mime"
range

range

2009-05-11 16:28

administrator   ~0009344

I had the same issue on another machine at the moment where "kernel-xen-devel" supposedly provided /usr/share/magic.mime.

Poking at the repository data in /var/cache/yum/updates (my update repo) didn't show anything strange, though.
ntsamba

ntsamba

2009-05-12 04:09

reporter   ~0009345

Here another strange happening. There is no xen-libs or Xen period on this machine and Never has been either.

Resolving Dependencies
--> Running transaction check
---> Package file.i386 0:4.17-15.el5_3.1 set to be updated
---> Package kexec-tools.i386 0:1.102pre-56.el5_3.2 set to be updated
--> Processing Dependency: /usr/share/magic.mime for package: httpd
--> Restarting Dependency Resolution with new changes.
--> Running transaction check
---> Package kernel-xen.i686 0:2.6.18-128.1.10.el5 set to be installed
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================================================================
 Package Arch Version Repository Size
=============================================================================================================================
Updating:
 file i386 4.17-15.el5_3.1 updates 316 k
 kexec-tools i386 1.102pre-56.el5_3.2 updates 526 k
Installing for dependencies:
 kernel-xen i686 2.6.18-128.1.10.el5 updates 16 M
range

range

2009-05-12 09:39

administrator   ~0009346

Attaching a tar.gz from my updates repository. The machine shows the following:

root@dryckjom:~# LANG=C yum --disablerepo=\* --enablerepo=update whatprovides "/usr/share/magic.mime"
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Excluding Packages in global exclude list
Finished
Importing additional filelist information
kernel-xen-devel-2.6.18-128.1.10.el5.x86_64 : Development package for building kernel
                                            : modules to match the kernel.
Matched from:
Filename : /usr/share/magic.mime



file-4.17-15.x86_64 : A utility for determining file types.
Matched from:
Other : Provides-match: /usr/share/magic.mime
range

range

2009-05-12 09:45

administrator   ~0009347

Okay, file is too large :(

http://people.centos.org/ralph/update.tar.bz2
Phil Schaffner

Phil Schaffner

2009-05-29 21:24

reporter   ~0009409

Similar problem, on i386 - additional packages involved.

# yum update
...
--> Processing Dependency: /usr/share/magic.mime for package: httpd
--> Restarting Dependency Resolution with new changes.
--> Running transaction check
---> Package audispd-plugins.i386 0:1.7.7-6.el5_3.2 set to be updated
--> Processing Dependency: audit-libs = 1.7.7-6.el5_3.2 for package: audispd-plugins
--> Processing Dependency: audit = 1.7.7-6.el5_3.2 for package: audispd-plugins
--> Finished Dependency Resolution
audispd-plugins-1.7.7-6.el5_3.2.i386 from updates has depsolving problems
  --> Missing Dependency: audit-libs = 1.7.7-6.el5_3.2 is needed by package audispd-plugins-1.7.7-6.el5_3.2.i386 (updates)
audispd-plugins-1.7.7-6.el5_3.2.i386 from updates has depsolving problems
  --> Missing Dependency: audit = 1.7.7-6.el5_3.2 is needed by package audispd-plugins-1.7.7-6.el5_3.2.i386 (updates)
Error: Missing Dependency: audit = 1.7.7-6.el5_3.2 is needed by package audispd-plugins-1.7.7-6.el5_3.2.i386 (updates)
Error: Missing Dependency: audit-libs = 1.7.7-6.el5_3.2 is needed by package audispd-plugins-1.7.7-6.el5_3.2.i386 (updates)

Similar but varying symptoms on a number of x86_64 and i386 systems. The common thread: Doing yum clean all fixes the problems.
Jskud

Jskud

2009-06-06 16:17

reporter   ~0009445

I saw a very similar problem: it was the httpd dependency on /usr/share/magic.mime that could not be satisfied.

Error: Missing Dependency: /usr/share/magic.mime is needed by package httpd-2.2.3-22.el5.centos.1.i386 (updates)

A (full clean)

    yum --enablerepo='*' clean all

fixed the problem.
peak

peak

2009-07-01 17:12

reporter   ~0009543

I have got a system exhibiting this problem (and enough free time and enthusiasm to examine it thoroughly):

# yum update file
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package file.i386 0:4.17-15.el5_3.1 set to be updated
--> Processing Dependency: /usr/share/magic.mime for package: httpd
--> Finished Dependency Resolution
httpd-2.2.3-22.el5.centos.1.i386 from installed has depsolving problems
  --> Missing Dependency: /usr/share/magic.mime is needed by package
httpd-2.2.3-22.el5.centos.1.i386 (installed)
Error: Missing Dependency: /usr/share/magic.mime is needed by package
httpd-2.2.3-22.el5.centos.1.i386 (installed)

Let us ask what package provides the file:

$ yum resolvedep /usr/share/magic.mime
0:file-4.17-15.i386

It reports the old version from base! But things get much stranger when we examine individual repos:

$ yum --disablerepo='*' --enablerepo='base' resolvedep /usr/share/magic.mime
0:file-4.17-15.i386
$ yum --disablerepo='*' --enablerepo='updates' resolvedep /usr/share/magic.mime
0:strace-4.5.18-2.el5.2.i386

"strace"?! What the hell?! Oh yes, it gets both "strace" and "file" when it asks for packages providing magic.mime but it picks the old version of "file" as a better choice later:

$ python -mpdb /usr/bin/yum resolvedep /usr/share/magic.mime
(Pdb) b /usr/lib/python2.4/site-packages/yum/__init__.py:2075
(Pdb) c
> /usr/lib/python2.4/site-packages/yum/__init__.py(2075)returnPackageByDep()
-> result = self._bestPackageFromList(pkglist)
(Pdb) pp pkglist
[<YumAvailablePackageSqlite : file-4.17-15.i386 (0x914790c)>,
 <YumAvailablePackageSqlite : strace-4.5.18-2.el5.2.i386 (0x8ea4ecc)>]

The culprit appears to be searchFiles method of YumSqlitePackageSack in /usr/lib/python2.4/site-packages/yum/sqlitesack.py. It finds pkgKey in filelists db and uses the value to get the package in primary db (via _sql_pkgKey2po), assuming identical packages have the same pkgKey in both databases. But this is a WRONG assumption.

Let's have a look at the databases (33e2f8cfb69975c29ba5b7797dea5685cd2f70b7 is the id of "file-4.17-15.el5_3.1.i386.rpm"):

$ sqlite3 /var/cache/yum/updates/filelists.xml.gz.sqlite
sqlite> select * from packages where pkgId = '33e2f8cfb69975c29ba5b7797dea5685cd2f70b7';
167|33e2f8cfb69975c29ba5b7797dea5685cd2f70b7
sqlite> select * from filelist where pkgKey = 167;
167|/usr/share|file/magic.mime/magic|dff
167|/usr/share/file|magic.mime.mgc/magic.mime/magic.mgc/magic|ffff
167|/usr/share/doc/file-4.17|README/LEGAL.NOTICE|ff
167|/usr/share/man/man1|file.1.gz|f
167|/usr/include|magic.h|f
167|/usr/share/man/man3|libmagic.3.gz|f
167|/usr/share/doc|file-4.17|d
167|/usr/share/misc|magic|f
167|/usr/lib|libmagic.so.1.0.0/libmagic.so.1/libmagic.so/libmagic.a|ffff
167|/usr/share/man/man5|magic.5.gz|f
167|/usr/bin|file|f

$ sqlite3 /var/cache/yum/updates/primary.xml.gz.sqlite
sqlite> select name from packages where pkgKey=167;
strace

The aformentioned method finds pkgKey of "file", i.e. 167, in filelists db but that value denotes "strace" in primary db.

As far as can tell, yum-metadata-parser is not designed to keep pkgKeys synchronized between databases but it probably picks identical values during fresh rebuild from XML files and this makes this bizzare problem go away after "yum clean all".

(Command outputs have been abridged to make them more readable.)
toracat

toracat

2009-08-05 19:24

manager   ~0009718

Some (if not all) of these cases may be fixed by the yum-metadata-parser package released as a FasTrack update:

http://rhn.redhat.com/errata/RHBA-2009-0440.html

If you wish to give this one a try, the binaries are available here:

http://elrepo.org/linux/fasttrack/el5/i386/RPMS/yum-metadata-parser-1.1.2-3.el5.elrepo.i386.rpm

http://elrepo.org/linux/fasttrack/el5/x86_64/RPMS/yum-metadata-parser-1.1.2-3.el5.elrepo.x86_64.rpm
Phil Schaffner

Phil Schaffner

2009-08-07 13:02

reporter   ~0009731

Not all issues are fixed. After updating to yum-metadata-parser-1.1.2-3.el5.elrepo.i386.rpm on a system that was a bit behind ran "yum update" and got the following errors:
--> Processing Dependency: /usr/lib/python2.4 for package: gamin-python
--> Processing Dependency: /usr/lib/python2.4 for package: libxml2-python
--> Finished Dependency Resolution
libxml2-python-2.6.26-2.1.2.7.i386 from installed has depsolving problems
  --> Missing Dependency: /usr/lib/python2.4 is needed by package libxml2-python-2.6.26-2.1.2.7.i386 (installed)
gamin-python-0.1.7-8.el5.i386 from installed has depsolving problems
  --> Missing Dependency: /usr/lib/python2.4 is needed by package gamin-python-0.1.7-8.el5.i386 (installed)
Error: Missing Dependency: /usr/lib/python2.4 is needed by package libxml2-python-2.6.26-2.1.2.7.i386 (installed)
Error: Missing Dependency: /usr/lib/python2.4 is needed by package gamin-python-0.1.7-8.el5.i386 (installed)

After "yum clean all" the update proceeded without errors.
t--om

t--om

2009-08-24 08:50

reporter   ~0009794

yum clean metadata was enough for me to fix this
peak

peak

2009-09-02 13:42

reporter   ~0009865

It seems the bug rears its ugly head when the following conditions are satisfied:

1. new packages are added to the repo

2. the original cached primary db is newer and contains more packages than the original cached filelists db

3. the current primary XML file contains more packages than the original cached primary db

4. the order of packages in XML files keeps changing

5. both cached primary and filelists dbs are updated using current XML files

6. dependency resolution needs to have a look at a package added to dbs during db update

I have got a saved Yum cache from mid-July that can trigger the bug. When the dbs are updated, mismatching keys are used for new packages and Yum thinks /usr/bin/python-2.4 is provided by Tomcat (very funny).

The problem disappeared when I installed the FasTrack yum-metadata-parser and reset the Yum cache back to the consistent saved state (!).

As far as I can tell from RHBA-2009-0440, they made the metadata parser always discard all cached data and rebuild the db from scratch. This should work as long as the order of packages in XML files (of the same version) is consistent and leads to the consistent assignment of db keys.
Dex

Dex

2010-01-26 14:33

reporter   ~0010836

I came across this when I combined FC and CentOS "file" packages, FC package seems not to contain "/usr/share/magic.mime" file, or is breaking some dependency bonds. Yum ignores this dependency, after manually installing file rpm, apache installs fine.
toracat

toracat

2010-01-26 15:49

manager   ~0010837

yum-metadata-parser-1.1.2-3.el5 that fixes the issue came out as part of CentOS 5.4. Closing the ticket as "resolved".

Issue History

Date Modified Username Field Change
2009-05-09 19:25 toracat New Issue
2009-05-09 19:25 toracat Description Updated
2009-05-10 13:23 st_gotbugs Note Added: 0009333
2009-05-11 06:00 mharris Note Added: 0009339
2009-05-11 06:26 iddover Note Added: 0009340
2009-05-11 12:46 range Note Added: 0009341
2009-05-11 16:28 range Note Added: 0009344
2009-05-12 04:09 ntsamba Note Added: 0009345
2009-05-12 09:39 range Note Added: 0009346
2009-05-12 09:45 range Note Added: 0009347
2009-05-15 08:32 range Relationship added has duplicate 0003573
2009-05-15 08:32 range Relationship deleted has duplicate 0003573
2009-05-29 21:24 Phil Schaffner Note Added: 0009409
2009-06-06 16:17 Jskud Note Added: 0009445
2009-07-01 17:12 peak Note Added: 0009543
2009-07-23 10:19 range Relationship added has duplicate 0003746
2009-08-05 18:48 range Relationship added has duplicate 0003762
2009-08-05 19:24 toracat Note Added: 0009718
2009-08-07 13:02 Phil Schaffner Note Added: 0009731
2009-08-24 08:50 t--om Note Added: 0009794
2009-09-02 13:42 peak Note Added: 0009865
2010-01-26 14:33 Dex Note Added: 0010836
2010-01-26 15:49 toracat Note Added: 0010837
2010-01-26 15:49 toracat Status new => resolved
2010-01-26 15:49 toracat Fixed in Version => 5.4