On Sun, 12 Feb 2012 16:43:24 +0100 Michael Biebl <bi...@debian.org> wrote:
> On 12.02.2012 16:15, Neil Williams wrote: > > On Sun, 12 Feb 2012 16:00:38 +0100 > > Michael Biebl <bi...@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/
pgpJBPnkZFgkk.pgp
Description: PGP signature