Bug#659588: libglib2.0-0: fails to install with foreign Multi-Arch
codehelp at debian.org
Sun Feb 12 15:15:20 UTC 2012
On Sun, 12 Feb 2012 16:00:38 +0100
Michael Biebl <biebl at debian.org> wrote:
> On 12.02.2012 13:48, Neil Williams wrote:
> > Setting up libglib2.0-0:armel (2.30.2-6) ...
> > /usr/lib/arm-linux-gnueabi/glib-2.0/glib-compile-schemas: 1: /usr/lib/arm-linux-gnueabi/glib-2.0/glib-compile-schemas: Syntax error: word unexpected (expecting ")")
> > /usr/lib/arm-linux-gnueabi/glib-2.0/gio-querymodules: 1: /usr/lib/arm-linux-gnueabi/glib-2.0/gio-querymodules: Syntax error: word unexpected (expecting ")")
> > dpkg: error processing libglib2.0-0:armel (--configure):
> Those tools are dpkg triggered.
dpkg triggers aren't a problem if the files being executed are
in /usr/bin - i.e. not in Multi-Arch paths or Multi-Arch: same
packages. Put the executables into a Multi-Arch: foreign package and
the triggers will work just fine.
> In all cases, aside gio-querymodules, there is an added || true.
What's the reason for not putting these executables in /usr/bin where
only one architecture would exist on the filesystem?
> I assume we should just do the same for gio-querymodules. This way, we'd
> still get the error messages, but the packages would install properly.
> Unless someone has a nicer idea how to handle dpkg triggers in the new
> multi-arch world.
Triggers, in general, are fine in Multi-Arch world, I've had no
trigger related problems, except this one. What matters is that the
processes being triggered here are in /usr/lib/ instead of /usr/bin.
Executing anything in /usr/lib/ in Multi-Arch world is just going to go
What is gio-querymodules meant to do as i386 on amd64? Is it going to
redo the work of the amd64 version? AFAICT these triggers should not be
run once-per-foreign-architecture but once per upgrade.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: not available
More information about the pkg-gnome-maintainers