Hmm, this doesn't look good. Can you run "yum clean all" and try again, please.

Thanks!

If this fails the exact yum version would be helpful.

Aargh, your reply came too late.

Meanwhile I did a 

yum update yum

which updated a bunch of packages, but now yum killed itself :(

# yum list
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:
g_assertion_message_expr

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, Jan  7 2008, 12:49:59) 
[GCC 4.1.2 20071124 (Red Hat 4.1.2-36)]

I have noted same problem as Thomas Gleixner, as discussed:
https://www.redhat.com/archives/fedora-devel-list/2008-January/msg02247.html

Florian: 
I renamed my yum cache dirs so that yum wouldn't be able to find it. Same issue.

Seth:
seth vidal wrote:
> On Tue, 2008-01-22 at 08:49 -0500, seth vidal wrote:
> I rebuild yum-metadata-parser into rawhide. Nothing changed in it - just
> a rebuild - let's see if that makes things better.

# rpm -Uvh yum-metadata-parser-1.1.2-5.fc9.i386.rpm
Preparing...                ########################################### 
[100%]
   1:yum-metadata-parser    ########################################### 
[100%]
[root@localhost packages]# yum
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

   /usr/lib/python2.5/site-packages/_sqlitecache.so: undefined symbol: 
g_assertion_message_expr

* so still the same.
===
rpm -Va yum\* rpm\* python\* sql\*|sort
S.5....T c /etc/yum.conf
[root@localhost packages]# cat /etc/yum.conf
[main]
cachedir=/var/cache/yum/
keepcache=1
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
metadata_expire=1800
failovermethod=priority

# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d
==
Paul Howarth:
> Does updating glib2 to the version in Rawhide help?
version was a .fc8.

tried: glib2-2.15.2-1.fc9.i386.rpm {it didn't pull in any other packages}.
Now yum yums :-)

and workaround: rpm -Uvh
http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/Packages/glib2-2.15.3-1.fc9.i386.rpm
is still yummy.

So does that suggest yum or yum-metadata-parser needs a specific minimum version
of glib2 ?
versions:
$ rpm -qa yum\* rpm\* python\* sql\* \*gcc\* glib\*|sort
glib2-2.15.3-1.fc9
glibc-2.7.90-4
glibc-common-2.7.90-4
libgcc-4.1.2-33
python-2.5.1-21.fc9
python-iniparse-0.2.3-3.fc9
python-libs-2.5.1-21.fc9
python-numeric-24.2-6.fc8
python-setuptools-0.6c7-2.fc8
python-urlgrabber-3.0.0-3.fc8
rpm-4.4.2.2-13.fc9
rpm-libs-4.4.2.2-13.fc9
rpm-python-4.4.2.2-13.fc9
sqlite-3.5.4-2.fc9
yum-3.2.8-2.fc9
yum-metadata-parser-1.1.2-5.fc9

I think it suggests that glib2 changed a function w/o incrementing the library 
at all. y-m-p didn't change so the change to glib2 should have done _something_.

reassigning.

 Note that while upstream probably don't want to increment the major release,
they should accept adding versions on the new symbols ... which are picked up by
rpm and so would also solve this problem.
 See the ustr package in Fedora for a simple example, if you/they aren't sure
how to do that.

I can reassure you that we (glib upstream) don't want symbol versions, thank you.

And symbol versions wouldn't have helped the least here anyway.

The problem is caused by old macros that expands to new symbols. 

Seth, I'm not sure why you reassigned this bug to glib2. 
What do you expect me to do ? I accept that the glib change is unfortunate, 
and I should perhaps have paid closer attention to avoid this problem. But
those macros are in rawhide now for better or worse, and the least invasive 
shortterm fix is to just require a new enough glib2 in yum-metadata-parser.

I reassigned it to glib b/c I wanted some input on what was going on. I got it.
I've added an explicit dep on glib > 2.14 to yum-metadata-parser's spec file in
rawhide.

... and every other app that is built against the new glib2 and uses that
function.  I hit this yesterday doing a quick upgrade of nautilus (and not the
rest of rawhide) to fix a crasher.  :-/

I don't have an easy answer, but it is something which has occurred more than
once now.  And symbol versioning would improve things, but definitely would do
so at a cost on maintenance of glib (and I'm not going to go as far as to say it
really "fixes")

> And symbol versioning would improve things

I honestly don't see how it would help here at all. Its a new symbol, not some
change in the semantic of an existing symbol. A symbols existence/nonexistence
is the one thing you can find out about it without resorting to symbol versions...

And yes, I'm going to look at what we can do to mend this issue before 2.16.

> I can reassure you that we (glib upstream) don't want symbol versions, thank you.

 Fair enough, I guess. But Here's another BZ#429970

> And symbol versions wouldn't have helped the least here anyway.

 This is pretty much the problem version symbols solve, from a depsolving POV.
As I said ustr used version symbols and was in Fedora:

% repoquery -q ustr 
ustr-0:1.0.2-3.fc8.x86_64
% repoquery --provides ustr
libustr-1.0.so.1()(64bit)
libustr-1.0.so.1(USTR_1.0)(64bit)
libustr-1.0.so.1(USTR_1.0.1)(64bit)
libustr-1.0.so.1(USTR_1.0.2)(64bit)
ustr = 1.0.2-3.fc8
% repoquery --repoid=development -q ustr
ustr-0:1.0.3-2.fc9.x86_64
% repoquery --repoid=development --provides ustr
libustr-1.0.so.1()(64bit)
libustr-1.0.so.1(USTR_1.0)(64bit)
libustr-1.0.so.1(USTR_1.0.1)(64bit)
libustr-1.0.so.1(USTR_1.0.2)(64bit)
libustr-1.0.so.1(USTR_1.0.3)(64bit)
ustr = 1.0.3-2.fc9

...if you use a 1.0.3 symbol, you get a dep. on
libustr-1.0.so.1(USTR_1.0.3)(64bit) ... and yum can do the right thing.

 Also if you look in scripts/ in ustr you'll find cmp_symbols_ver.sh ... which
does a diff. between the version file and the symbols in the library ... it's
not like you have to do this stuff by hand.
 But anyway...

Ah, maybe I didn't have the full picture on how symbol versions interact with
rpms dependency collector, and symbol versions do indeed solve this.

*** Bug 429041 has been marked as a duplicate of this bug. ***