0003613: latest package "file" causes yum error

Notes
(0009333) st_gotbugs (reporter) 2009-05-10 13:23	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.

(0009339) mharris (reporter) 2009-05-11 06:00	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.

(0009340) iddover (reporter) 2009-05-11 06:26	Same happens to me in 2 DEll 1950 w centos 5.3 the "yum clean all" command solves the thing...

(0009341) range (administrator) 2009-05-11 12:46	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"

(0009344) range (administrator) 2009-05-11 16:28	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.

(0009345) ntsamba (reporter) 2009-05-12 04:09	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

(0009346) range (administrator) 2009-05-12 09:39	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

(0009347) range (administrator) 2009-05-12 09:45	Okay, file is too large :( http://people.centos.org/ralph/update.tar.bz2 [^]

(0009409) Phil Schaffner (reporter) 2009-05-29 21:24	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.

(0009445) Jskud (reporter) 2009-06-06 16:17	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.

(0009543) peak (reporter) 2009-07-01 17:12	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.)

(0009718) toracat (developer) 2009-08-05 19:24	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 [^]

(0009731) Phil Schaffner (reporter) 2009-08-07 13:02	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.

(0009794) t--om (reporter) 2009-08-24 08:50	yum clean metadata was enough for me to fix this

(0009865) peak (reporter) 2009-09-02 13:42	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.

(0010836) Dex (reporter) 2010-01-26 14:33	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.

(0010837) toracat (developer) 2010-01-26 15:49	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	Assigned To	=> kbsingh@karan.org
2009-05-09 19:25	toracat	Description Updated
2009-05-10 13:23	st_gotbugs	Note Added: 0009333
2009-05-11 05:56	mharris	Issue Monitored: mharris
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 12:46	range	Issue Monitored: range
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