Debian Bug report logs - #659588
libglib2.0-0: fails to install with foreign Multi-Arch

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Neil Williams <codehelp@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: libglib2.0-0: fails to install with foreign Multi-Arch

Date: Sun, 12 Feb 2012 12:48:34 +0000

Package: libglib2.0-0
Version: 2.30.2-6
Severity: normal

With the new upload of zlib1g, it is now possible to install glib
as a Multi-Arch package. It works for i386 on amd64 but not for
armel on amd64 - due to execution of the wrong executable
in the maintainer scripts:

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):
 subprocess installed post-installation script returned error exit status 2
dpkg: dependency problems prevent configuration of libatk1.0-0:armel:
 libatk1.0-0:armel depends on libglib2.0-0 (>= 2.16.0); however:
  Package libglib2.0-0:armel is not configured yet.
dpkg: error processing libatk1.0-0:armel (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 libglib2.0-0:armel

The compile-schemas and querymodules commands may need to check the
native / principle architecture and not run the executables in the
multiarch lib path. Alternatively, glib-compile-schemas and
gio-querymodules may need to move into a different Multi-Arch: foreign
package and be moved into /usr/bin.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libglib2.0-0 depends on:
ii  libc6              2.13-26
ii  libffi5            3.0.10-3
ii  libpcre3           8.12-4
ii  libselinux1        2.1.0-4.1
ii  multiarch-support  2.13-26
ii  zlib1g             1:1.2.6.dfsg-1

Versions of packages libglib2.0-0 recommends:
ii  libglib2.0-data   2.30.2-6
ii  shared-mime-info  0.90-1

libglib2.0-0 suggests no packages.

-- no debconf information

Message #10 received at 659588@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Neil Williams <codehelp@debian.org>, 659588@bugs.debian.org

Subject: Re: Bug#659588: libglib2.0-0: fails to install with foreign Multi-Arch

Date: Sun, 12 Feb 2012 16:00:38 +0100

[Message part 1 (text/plain, inline)]

On 12.02.2012 13:48, Neil Williams wrote:
> Package: libglib2.0-0
> Version: 2.30.2-6
> Severity: normal
> 
> With the new upload of zlib1g, it is now possible to install glib
> as a Multi-Arch package. It works for i386 on amd64 but not for
> armel on amd64 - due to execution of the wrong executable
> in the maintainer scripts:
> 
> 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.
Afaics, we will have this issue in various packages:
libgdk-pixbuf2.0-0
libgtk2.0-0
libgtk-3-0
libglib2.0-0

They all install path based triggers which call a support binary from
the multi-arch library path.
In all cases, aside gio-querymodules, there is an added || true.

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.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #15 received at 659588@bugs.debian.org (full text, mbox, reply):

From: Neil Williams <codehelp@debian.org>

To: biebl@debian.org

Cc: 659588@bugs.debian.org

Subject: Re: Bug#659588: libglib2.0-0: fails to install with foreign Multi-Arch

Date: Sun, 12 Feb 2012 15:15:20 +0000

[Message part 1 (text/plain, inline)]

On Sun, 12 Feb 2012 16:00:38 +0100
Michael Biebl <biebl@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
wrong.

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.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

[Message part 2 (application/pgp-signature, inline)]

Message #20 received at 659588@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Neil Williams <codehelp@debian.org>

Cc: 659588@bugs.debian.org

Subject: Re: Bug#659588: libglib2.0-0: fails to install with foreign Multi-Arch

Date: Sun, 12 Feb 2012 16:43:24 +0100

[Message part 1 (text/plain, inline)]

On 12.02.2012 16:15, Neil Williams wrote:
> On Sun, 12 Feb 2012 16:00:38 +0100
> Michael Biebl <biebl@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
> wrong.
> 
> 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.
> 

gio-quermodules generates a cache files in a arch specific location for
the plugins/extensions specific for this arch. So moving them to
/usr/bin seems wrong.

/usr/lib/x86_64-linux-gnu/gio/modules/giomodule.cache

The other tools do similar things

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #25 received at 659588@bugs.debian.org (full text, mbox, reply):

From: Neil Williams <codehelp@debian.org>

To: biebl@debian.org

Cc: 659588@bugs.debian.org

Subject: Re: Bug#659588: libglib2.0-0: fails to install with foreign Multi-Arch

Date: Sun, 12 Feb 2012 16:05:26 +0000

[Message part 1 (text/plain, inline)]

On Sun, 12 Feb 2012 16:43:24 +0100
Michael Biebl <biebl@debian.org> wrote:

> On 12.02.2012 16:15, Neil Williams wrote:
> > On Sun, 12 Feb 2012 16:00:38 +0100
> > Michael Biebl <biebl@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):

> > 
> > What's the reason for not putting these executables in /usr/bin where
> > only one architecture would exist on the filesystem?
> > 
> > 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.
> > 
> 
> gio-quermodules generates a cache files in a arch specific location for
> the plugins/extensions specific for this arch. So moving them to
> /usr/bin seems wrong.

Yes, but what purpose is that cache file when the binaries for that
architecture cannot be executed?

Why is it being created unconditionally? What possible usage is the
foreign architecture cache? Unless *the majority* of foreign
architecture caches are *actually* going to be loaded and useful *at
runtime* on a different native architecture, there is no point
generating these cache files in an architecture-dependent manner from
the libraries, for every foreign architecture on every upgrade.

Yes, the cache data is arch-dependent - my point is that I don't see
any reason for it being generated for the foreign architecture and this
is easily managed by making the package running the triggers be
Multi-Arch: foreign, including the executables in /usr/bin with the
cache itself in /var/

Exactly what is going to happen in these situations:

native architecture is amd64
foreign architecture is i386 - what processes are going to need the
i386 cache data and why?

native architecture is amd64
foreign architecture is armel - that cache file is completely useless.
It will need to be regenerated on device when the armel package is
installed on armel.

> /usr/lib/x86_64-linux-gnu/gio/modules/giomodule.cache

/var/cache/gio/ ?

Modifying /usr/lib/ in maintainer scripts isn't a nice thing to do IMHO,
we have /var after all. 

> The other tools do similar things

... and have perennially caused failures with all prior methods of
cross-compilation ...

We have a chance here to fix this properly. Put the executables
in /usr/bin Multi-Arch: foreign, put the cache file in /var/cache/ and
have one cache per system, not one per architecture (seeing as it is
created/updated at install/upgrade, not compilation).

Just because the data is arch-dependent does not mean that every
Multi-Arch: same package must try to generate another unused copy of
the cache. This is what Multi-Arch: foreign & /var are meant to provide.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

[Message part 2 (application/pgp-signature, inline)]

Message #30 received at 659588@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Neil Williams <codehelp@debian.org>

Cc: 659588@bugs.debian.org

Subject: Re: Bug#659588: libglib2.0-0: fails to install with foreign Multi-Arch

Date: Sun, 12 Feb 2012 17:28:19 +0100

[Message part 1 (text/plain, inline)]

On 12.02.2012 17:05, Neil Williams wrote:
> On Sun, 12 Feb 2012 16:43:24 +0100
> Michael Biebl <biebl@debian.org> wrote:

>>
>> gio-quermodules generates a cache files in a arch specific location for
>> the plugins/extensions specific for this arch. So moving them to
>> /usr/bin seems wrong.
> 
> Yes, but what purpose is that cache file when the binaries for that
> architecture cannot be executed?

What if they can, like i386 and amd64?

> Why is it being created unconditionally? What possible usage is the
> foreign architecture cache? Unless *the majority* of foreign
> architecture caches are *actually* going to be loaded and useful *at
> runtime* on a different native architecture, there is no point
> generating these cache files in an architecture-dependent manner from
> the libraries, for every foreign architecture on every upgrade.

The cache is used at runtime, yes.
The major use case for multi-arch is running i386 on amd64, no?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #35 received at 659588@bugs.debian.org (full text, mbox, reply):

From: Neil Williams <codehelp@debian.org>

To: biebl@debian.org

Cc: 659588@bugs.debian.org

Subject: Re: Bug#659588: libglib2.0-0: fails to install with foreign Multi-Arch

Date: Sun, 12 Feb 2012 16:29:09 +0000

[Message part 1 (text/plain, inline)]

On Sun, 12 Feb 2012 16:05:26 +0000
Neil Williams <codehelp@debian.org> wrote:

> > gio-quermodules generates a cache files in a arch specific location for
> > the plugins/extensions specific for this arch. So moving them to
> > /usr/bin seems wrong.
> 
> Yes, but what purpose is that cache file when the binaries for that
> architecture cannot be executed?

Ignore that, got it mixed up myself.

The cache data appears package-selection-specific more than anything
else, but as i386 could have a different selection to amd64, I can see
what's going on now.

I'll look again at what happens with cross-compilation once that work
restarts. (Still seems odd to modify /usr/lib/ in the maintainer
scripts.)

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

[Message part 2 (application/pgp-signature, inline)]

Message #40 received at 659588-done@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: 659588-done@bugs.debian.org, Neil Williams <codehelp@debian.org>

Subject: libglib2.0-0: fails to install with foreign Multi-Arch

Date: Sun, 04 Mar 2012 20:38:27 +0100

[Message part 1 (text/plain, inline)]

Version: 2.31.8-1

This was part of the experimental upload

glib2.0 (2.30.2-7) UNRELEASED; urgency=low

  * libglib2.0-0.postinst.in:
    + Encapsulate gio-querymodules calls in || true statements.
      Closes: #659588.
    + Only run gio-querymodules on the non-multiarch path for the host»
      architecture.
  * rules: add substitution for #ARCH# for the above change.

 -- Josselin Mouette <joss@debian.org>  Thu, 16 Feb 2012 12:21:51 +0100

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Send a report that this bug log contains spam.