On Sat, 2 Apr 2005, John Franks wrote: > Yes. This affects machines upgraded from 3.03 to 3.04. As I'm now reporting, this problem has now surfaced in 3.0.3 itself. > An error message was generated by librsvg2, way back when, during > the upgrade. In 3.0.3 the error had not appeared before, but it's here now ... > The problem seems to be that the upgrade from librsvg2-2.2.3-2 to > librsvg2-2.2.3-6 had a post install script fail and > so both versions are left installed. Confirmed for 3.0.3 > I think this failure is caused > because the script tries to run > /etc/gtk-2.0/i386-redhat-linux-gnu/gdk-pixbuf.loaders > which is now > /etc/gtk-2.0/i686-redhat-linux-gnu/gdk-pixbuf.loaders There certainly does now seem to be such a file: $ ls -l /etc/gtk-2.0/*/gdk-pixbuf.loaders -rw-r--r-- 1 root root 2644 Apr 3 05:52 /etc/gtk-2.0/i686-redhat-linux-gnu/gdk-pixbuf.loaders and its datestamp suggests it came from the overnight yum update. > Having both versions of librsvg2 installed is innocuous until you try to > install the latest gtk2 which conflicts with something in the older > librsvg2. > > So what to do? I have this on about fifty computers. Here is what I am > doing -- it's not pretty, but it seems to work. > > rpm -q librsvg2 (check you really have two versions installed) > > rpm -e librsvg2-2.2.3-2 > (remove the old one -- this generates errors, but works) Confirmed for 3.0.3 At this point, $ rpm -V librsvg2 missing /usr/share/doc/librsvg2-2.2.3 missing d /usr/share/doc/librsvg2-2.2.3/AUTHORS missing d /usr/share/doc/librsvg2-2.2.3/COPYING missing d /usr/share/doc/librsvg2-2.2.3/COPYING.LIB missing d /usr/share/doc/librsvg2-2.2.3/ChangeLog missing d /usr/share/doc/librsvg2-2.2.3/NEWS missing d /usr/share/doc/librsvg2-2.2.3/README > rpm -Uvh --force librsvg2-2.2.3-6 That would be something like rpm -Uvh --force librsvg2-2.2.3-6.i386.rpm > (Actually we removed some docs we want to keep so re-install > the new version. This generates errors too, but seems ok.) That all seems to fit, in 3.0.3 also. > rpm -V librsvg2 (looks clean) Confirmed However, I spotted a rather curious item left around after the manual procedure (which was performed at 12:48 local time): -rw-r--r-- 1 root root 0 Apr 3 12:48 /etc/gtk-2.0/gdk-pixbuf.loaders whereas on another machine that had run the defective update but hasn't had the manual procedure applied, this file was a duplicate of /etc/gtk-2.0/i686-redhat-linux-gnu/gdk-pixbuf.loaders although with a different last-modified date: -rw-r--r-- 1 root root 2644 Nov 15 13:12 /etc/gtk-2.0/gdk-pixbuf.loaders /etc/gtk-2.0/i686-redhat-linux-gnu: -rw-r--r-- 1 root root 2644 Apr 3 06:25 gdk-pixbuf.loaders > yum update (This should work now.) At this point in the proceedings with 3.0.3, no further updates are found at this point. I think that's what we'd expect. We'd hope to be back in synch - but I'm worried about the above discrepancy (and worried that there might be other oddities which I hadn't found). I hardly need to mention that this degree of manual intervention doesn't scale ;-) so IMHO some kind of scripted solution is needed in the actual update tree, so that it'll get applied by the routine yum updates. thanks