Package: libglib2.0-0 Version: 2.54.2-1 File: /usr/lib/<triplet>/glib-2.0/glib-compile-resources User: helm...@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