Bug#885019: reconsider placement of glib-compile-resources

[Helmut Grohne]

Package: libglib2.0-0
Version: 2.54.2-1
File: /usr/lib/<triplet>/glib-2.0/glib-compile-resources
User: helmutg at debian.org
Usertags: rebootstrap
Control: affects -1 + src:empathy src:gupnp-tools

The packages listed under affects fail to cross build from source,
because they fail running glib-compile-resources with an "Exec format
error". Normally, I send patches for such issues, but this time it is
not clear to me how to fix the mess, so I file a discussion bug seeking
maintainer input to figure the right direction. Let me start with some
background.

glib-compile-resources has a "dual" life. It lives in
/usr/lib/<triplet>/glib-2.0/ (in libglib2.0-0), but it also lives in
/usr/bin (as a symlink pointing to the former in libglib2.0-bin). Most
packages use the /usr/bin one, but not all do. Notable exceptions
include the affected packages. Having this tool both on an
architecture-dependent path and in an m-a:foreign package seems wrong to
me: Either the tool has architecture-dependent behaviour, then
libglib2.0-bin shouldn't symlink it, or it doesn't and then it shouldn't
live on an architecture-dependent path.

But the irritation doesn't stop here. As far as I can tell,
glib-compile-resources is a development tool. Yet it is placed into the
shared library package. Why does it have to be in the shared library in
the first place?

Worse, the path is independent of the soname of the library, so any
prospective soname bump (that will never happen) would cause a file
conflict. On paper, this is a violation of Debian policy section 8.2.

So how do packages actually end up using that architecture-dependent
path rather than the /usr/bin symlink? It turns out that gio-2.0.pc says

    glib_compile_resources=${prefix}/lib/<triplet>/glib-2.0/glib-compile-resources

and at least gupnp-tools queries this variable for discovering which
glib-compile-resources to use.

Given the above, the placement of glib-compile-resources seems
questionable at best. There are a number of ways to attack the cross
compilation problem:

1. Reconsider where to place glib-compile-resources.
2. Split glib-compile-resources to a m-a:foreign package.
3. Fix the path in gio-2.0.pc.
4. Tell users of gio-2.0.pc not to query for glib_compile_resources.

Given the breadth of potential solutions, I think discussing them first
is in order.

Helmut