Bug 143547 - (IT_66071) post scriptlet failed in U4 update
post scriptlet failed in U4 update
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: librsvg2 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Matthias Clasen
Depends On:
Blocks: 168424 171049
  Show dependency treegraph
Reported: 2004-12-22 01:50 EST by Dag Wieers
Modified: 2007-11-30 17:07 EST (History)
8 users (show)

See Also:
Fixed In Version: RHBA-2006-0040
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-15 10:30:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dag Wieers 2004-12-22 01:50:08 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041020 Galeon/1.3.18

Description of problem:
When updating the system from U3 to U4 using apt, I get the following

########################################### [ 42%]
/var/tmp/rpm-tmp.23030: line 2: /usr/bin/update-gdk-pixbuf-loaders: No
such file or directory
error: %post(librsvg2-2.2.3-6) scriptlet failed, exit status 127

After this update, we end up with 2 packages:

[root@emyn root]# rpm -q librsvg2

When installing the older package, it seemed to haved suffered from
this too:

[root@emyn root]# rpm -e librsvg2-2.2.3-2
/var/tmp/rpm-tmp.19397: line 2: gdk-pixbuf-query-loaders: command not
error: %postun(librsvg2-2.2.3-2) scriptlet failed, exit status 127

The problem which we experienced with our repositories too, is related
to a change from /usr/bin/gdk-pixbuf-query-loaders to

For this, the new tool /usr/bin/update-gdk-pixbuf-loaders has been
made. What we do in our packages is:

/usr/bin/update-gdk-pixbuf-loaders . &>/dev/null || :

### Backward compatibility for gtk < 2.4.13-9
[ -x %{_bindir}/gdk-pixbuf-query-loaders ] && \
    %{_bindir}/gdk-pixbuf-query-loaders > \
        %{_sysconfdir}/gtk-2.0/gdk-pixbuf.loaders || :

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Additional info:
Comment 1 Bernd Bartmann 2004-12-27 16:44:16 EST
Same here:

/var/tmp/rpm-tmp.48163: line 2: gdk-pixbuf-query-loaders: command not
error: %postun(librsvg2-2.2.3-2) scriptlet failed, exit status 127
Comment 2 Jos Vos 2005-01-02 07:08:59 EST
A few comments:

update-gdk-pixbuf-loaders is in gtk2-2.2.4-12, so a "Prereq: gtk2 >=
2.2.4-12", or maybe better a "Prereq:
/usr/bin/update-gdk-pixbuf-loaders" should be included in the package.

Non-standard commands used in the pre/post scripts should always be
prereq'ed, IMHO.

Even if update-gdk-pixbuf-loaders exists, it fails! This is because
the %post(un) scripts use %{_arch}-%{_host_vendor}-%{_host_os}, while
gtk2 uses %{_host} and the difference is the use of i386 resp. i686 in
the name.  So the librsvg2 scripts should use %{_host} too.
Comment 3 Jos Vos 2005-01-02 07:37:37 EST
Hmmm... related to my previous comment (3) I now see:

The new gtk2 contains a directory /etc/gtk-2.0/i686-redhat-linux-gnu,
this seems to be wrong, as it contains the architecture of the *build*
host (i686), not that of the *target* host (i386 in the case of gtk2).
 So, using %{_host} as suggested in (3) would fail again on
architectures that are not the same as the build host (like athlon).
Comment 4 Jos Vos 2005-01-02 07:52:51 EST
Correction of my comment (4):

As %{_host} is only interpreted on the build host, installing on
athlon will not fail.  But, still, I think using %{_host} for file
naming is not recommended for packages that are not bound to a
specific (sub)architecture.
Comment 5 Jos Vos 2005-01-02 10:57:57 EST
See also my bug #143950 for gtk2 that I just filed.
Comment 6 Zenon Panoussis 2005-04-02 16:00:36 EST
This problem now blocks 'rpm -Fhv gtk2-2.2.4-15.i386.rpm' unless one 
manually does 'rpm -e librsvg2-2.2.3-2' first. As a result, up2date 
and its cousins probably fail to push the latest gtk2 update. 
Comment 13 Red Hat Bugzilla 2006-03-15 10:30:48 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.