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