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

[Neil Williams]

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

> On 12.02.2012 16:15, Neil Williams wrote:
> > 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):

> > 
> > 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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20120212/dcc3a645/attachment-0001.pgp>