Bug#683593: libglib2.0-dev: please mark libglib2.0-dev multi-arch: same

[Simon McVittie]

On Sat, 23 May 2015 at 02:29:12 +0200, Francois Gouget wrote:
> The only issues I noticed are the following binaries:
>   /usr/bin/glib-genmarshal
>   /usr/bin/gobject-query
>   /usr/bin/gtester
> 
> Is there any reason not to move them to a separate Multi-Arch: foreign
> package?

As Michael Biebl already mentioned on the merged bug #648621,
if the foreign-architecture version produces architecture-independent
output or is otherwise non-problematic, they can move. If the architecture
matters, they can't.

Do foreign architectures' glib-genmarshal always produce the same output
as the native version?

gobject-query is purely informational, so it *probably* isn't a
build-dependency for anything.

gtester is a test-runner; can tests run successfully under a foreign
gtester? <https://codesearch.debian.net/results/Makefile.gtester/page_0>
suggests that d-conf/unstable would be a good test-case, although you
would have to enable build-time checks.

There are other binaries mentioned in the patch on the merged bug
#648621. Do those all produce architecture-independent results?

> One option would be libglib2.0-bin but it would also be possible to
> add a new package, libglib2.0-tools for instance.

libglib2.0-dev-bin would probably be less confusing, as in the patch
on the merged bug. libglib2.0-dev would still have to depend on it.

There is a patch from Riku Voipio on the merged bug, but it is
outdated; gregory hainaut tried updating the patch, but the result appears
to be broken, and he didn't attach the updated version. If you want this
to move forward, updating the patch seems like the obvious first step.

Jonathan Nieder raised some technical concerns about ignoring failure of
gio-querymodules, also on the merged bug. A simpler version as a first
step would be to assume (as we do now) that we can execute the foreign
architecture's binaries without issues, which would solve the common
"i386 on amd64" and "armhf with qemu on any sufficiently fast host" cases.

Regards,
    S