Red Hat Bugzilla – Bug 429041
Last modified: 2014-01-21 18:01:18 EST
Description of problem:
"yum --enablerepo=development update yum\* rpm\*" on Fedora 8 gives you a broken
yum. Trying to run it gives the following error:
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:
/usr/lib64/python2.5/site-packages/_sqlitecache.so: undefined symbol:
Please install a package which provides this module, or
verify that the module is installed correctly.
It's possible that the above module doesn't match the
current version of Python, which is:
2.5.1 (r251:54863, Oct 30 2007, 13:45:26)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)]
If you cannot solve this problem yourself, please go to
the yum faq at:
/usr/lib64/python2.5/site-packages/_sqlitecache.so is owned by
yum-metadata-parser, so I'm assuming it should have a dependency on something in
the newer version of python in rawhide.
Version-Release number of selected component (if applicable):
rpm x86_64 22.214.171.124-12.fc9 development 1.2 M
rpm-libs x86_64 126.96.36.199-12.fc9 development 922 k
rpm-python x86_64 188.8.131.52-12.fc9 development 65 k
yum noarch 3.2.8-2.fc9 development 509 k
yum-metadata-parser x86_64 1.1.2-4.fc9 development 26 k
Steps to Reproduce:
1. Install Fedora 8.
2. yum --enablerepo=development update yum\* rpm\*
Working yum. :-)
This problem still affects yum-metadata-parser-1.1.2-5, at least on i386.
I don't know if this helps tracking down what is broken, but a _work_around_
kludge until yum-metadata-parser is fixed:
pull the _sqlitecache.so (and just that file) from a
yum-metadata-parser-1.1.2-1.fc8.i386.rpm and use it to replace the one installed
by yum-metadata-parser-1.1.2-5.fc9.i386.rpm, and yum works again.
the problem is glib2 changed the functions it calls without incrementing the
version of the library. So the dependency in yum-metadata-parser has no way of
knowing it needs to be changed. reassigning to the glib maintainers.
I don' t know since when it is supported to selectively install development
versions of packages onto older releases.
Sure, the inaccurate dependency is unfortunate.
*** This bug has been marked as a duplicate of 428847 ***