1) Running foreign-arch binaries during install:

Is saying "| true" in the postinst sufficient? (gives a warning but
stops it being fatal). Or could do:
if (command fails && installing as native arch) then barf
else OK
installing as native arch= (DEB_BUILD_ARCH = dpkg --print-architecture)
(can we rely on DEB_BUILD_ARCH being settable?)
 do we do this in the postinst or in the build system - why was this changed
 and what are the problems of reverting it?
 failures on armel/armhf are not failures on amd64 when installing on i386
 Need a way to detect whether a postinst can safely call an ELF under the
 current configuration or should skip it and return true.
Examples:
 libgvc5: libgvc5-config-update
 libglib2.0-0: glib-compile-schemas, gio-querymodules (fixed to not
fail)
 libgdk-pixbuf2.0-0: gdk-pixbuf-query-loaders
 libgtk2.0-0: gtk-query-immodules-2.0
 libgtk-3-0: gtk-query-immodules-3.0

2) chrpath. Is skipping good enough?
 make chrpath smarter to know what is happening.
 new version of chrpath supposedly works (see #578502/#502259)
3) multiarching perl. Things do link directly against libperl so we
need to make that lib MA:same or allowed. Just one file matters:
/usr/lib/libperl.so.5.14. Move it to libperl, or leave it where it is
and make perl M-A:Allowed? We need to upgrade libperl and
perl-base together reliably. (There is already libperl5.14 but it
doesn't contain /usr/lib/libperl.so.5.14. Why not?)
 need to have a go at making libperl5.14 MultiArch allow. i386 has a static
 linkage package for performance reasons, others are dummy packages.
 also need the arch-specific config for each architecture so that other
 perl modules can be cross-built.
 perl-dev for each arch "how I built myself"
3.1 pull the cross-config stuff out of dpkg-cross and make it a cross-config
package which also contains support material and symlinks for other requirements
(after Wheezy) some of the dpkg-cross content itself needs to be architecture
specific, so this could provide the $triplet-config packages.
4) multiarching python. /usr/bin/python-config is nearly arch-indep,
but the --cflags option isn't. --libs won't be when paths are multiarched


5) lots of -config files: curl-config, freetype-config, guile-config,
icu-config, kde4-config, krb5-config, libgcrypt-config, pcre-config

e.g: pcre-config --libs
-L/usr/lib/x86_64-linux-gnu -lpcre
curl-config --libs
-L/usr/lib/x86_64-linux-gnu -lcurl

call them as <triplet>-config.

some are just old and nobody has explained why they need to be removed.
Removing them does mean build breakage in reverse dependencies and these need
to change at the same time == transitions.

 ICU: <xnox> Back in 2009 I filed pkg-config request for ICU
      <xnox> http://bugs.icu-project.org/trac/ticket/6981
      <xnox> and it looks like it was fixed
      <xnox> but this is not shipped in Debian/Ubuntu yet.


6) pkg-config called as <triplet>-pkg-config
currently pkg-config includes /usr/share/pkg-config-crosswrapper
links are provided by pkg-config-arch packages

7) gobject introspection
https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/CrossPatching
https://wiki.linaro.org/PeterPearse/GobjectIntrospection