Bug#842442: libglib2.0-dev: move glib-genmarshal to a Multi-Arch: foreign package

[Simon McVittie]

On Thu, 02 Mar 2017 at 07:53:25 +0100, Helmut Grohne wrote:
>  * The major goal of 648621 is to make libglib2.0-dev Multi-Arch: same.
>  * The only goal of 842442 is to make glib-genmarshal executable during
>    cross builds.
>  * 842442 covers a small subset of 648621.

This seems like good reasoning for having #842442 block #648621, and
treating it as separate.

At this point I don't think this is going to happen for stretch unless
the release team particularly want it to (NEW packages with unpredictable
delays seem like a bad idea right now) but I'm going to apply Helmut's
patch to the experimental branch, with suitable version adjustments.

>  * Thus 842442 is applicable right now, while 648621 needs someone
>    working out the remaining issues[1]. Adding the help tag.

Summarizing those issues:

* multiarch concerns about gio-querymodules (but perhaps those have
  already been worked around in #659588 by making failure of
  gio-querymodules non-fatal, on the basis that if we can't run
  $host executables, it doesn't really matter whether we can load
  $host GIO modules or not, because there can't be a suitable process
  to dlopen them into)

* py3compile, py3clean are or were problematic in M-A: same packages,
  which might imply that gdbus-codegen should move to -dev-bin
  (I'm reasonably sure it's arch-independent)

* there are some less important binaries (not commonly run at
  build time), notably gobject-query, whose multiarch status is unclear
  and needs further investigation

Regards,
    S