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
