hicolor-icon-theme installation/dependency problem

2 messages, 2 authors, 2011-02-01 · open the first message on its own page

hicolor-icon-theme installation/dependency problem

From: Fabian Ruff <hidden>
Date: 2011-02-01 13:43:13

Hi,

first of all I'm not sure if this is the right mailing-list to post my question. Please point me to the right one if it isn't.

I've stumbled upon a problem building an recipe for custom software that depends on totem-pl-parser which itself depends on hicolor-icon-theme (which seems to be introduced by the gnome bbclass the totem-pl-parser recipe inherits from).

The installation of the hicolor-icon-theme fails at the postinstallation step because the directory /etc/gtk-2.0 and the binaries gdk-pixbuf-query-loaders & gtk-update-icon-cache don't exist.
The postinst script of hicolor-icon-them is as follows:
#!/bin/sh
if [ "x$D" != "x" ]; then
        exit 1
fi
# Update the pixbuf loaders in case they haven't been registered yet
gdk-pixbuf-query-loaders > /etc/gtk-2.0/gdk-pixbuf.loaders

for icondir in /usr/share/icons/* ; do
    if [ -d $icondir ] ; then
        gtk-update-icon-cache -qt  $icondir
    fi
done
I believe this postinstallation step is added by the gtk-icon-cache class the hicolor-icon-theme recipe inherits from.

I don't know which package provides this binaries/directory but as the package hicolor-icon-theme explicitly has no RDEPENDS set this seems wrong somehow.
Installing hicolor-icon-theme via opkg from a standard console-image installation leaves the package manager in an inconsistent state with a half installed hicolor-icon-theme package which additionally can't be removed anymore because the postrm step also expects gtk-update-icon-cache to be available.

Any suggestions how to fix this or how this was intended to work?
I want to use totem-pl-parser with the least possible additional software and hope this is possible without unfolding a complete gnome/gtk universe in my installation.

Cheers,
Fabian






Re: hicolor-icon-theme installation/dependency problem

From: Koen Kooi <hidden>
Date: 2011-02-01 14:01:00

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01-02-11 14:28, Fabian Ruff wrote:
Hi,

first of all I'm not sure if this is the right mailing-list to post my
question. Please point me to the right one if it isn't.

I've stumbled upon a problem building an recipe for custom software that
depends on totem-pl-parser which itself depends on hicolor-icon-theme
(which seems to be introduced by the gnome bbclass the totem-pl-parser
recipe inherits from).

The installation of the hicolor-icon-theme fails at the postinstallation
step because the directory /etc/gtk-2.0 and the binaries
gdk-pixbuf-query-loaders & gtk-update-icon-cache don't exist.
The postinst script of hicolor-icon-them is as follows:
quoted
#!/bin/sh
if [ "x$D" != "x" ]; then
        exit 1
fi
# Update the pixbuf loaders in case they haven't been registered yet
gdk-pixbuf-query-loaders > /etc/gtk-2.0/gdk-pixbuf.loaders

for icondir in /usr/share/icons/* ; do
    if [ -d $icondir ] ; then
        gtk-update-icon-cache -qt  $icondir
    fi
done
I believe this postinstallation step is added by the gtk-icon-cache
class the hicolor-icon-theme recipe inherits from.

I don't know which package provides this binaries/directory but as the
package hicolor-icon-theme explicitly has no RDEPENDS set this seems
wrong somehow.
Installing hicolor-icon-theme via opkg from a standard console-image
installation leaves the package manager in an inconsistent state with a
half installed hicolor-icon-theme package which additionally can't be
removed anymore because the postrm step also expects
gtk-update-icon-cache to be available.

Any suggestions how to fix this or how this was intended to work?
I want to use totem-pl-parser with the least possible additional
software and hope this is possible without unfolding a complete
gnome/gtk universe in my installation.
In recent gtk versions gdk-pixbuf is now split out again (after being
merged in 2002). Using that would be a good solution. The intermediate
solution would be to make the make it rdepend on the current pixbug package.

Now, the *real* solution would be to check if an icon cache is actually
needed before trying to run gtk-update-icon-cache. ISRT the cache format
is an FDO spec, but I'm not sure.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFNSBHJMkyGM64RGpERAuGiAKCb2nzkVR0U04ME4Vh4TpR5GhtQRgCfRItf
GjRUnhHjeG1ep3gSMNhSVdw=
=OMGv
-----END PGP SIGNATURE-----


Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help