Bug#1029957: g-ir-scanner: produces FHS violations by putting architecture-dependent files in /usr/share

[Simon McVittie]

On Sun, 29 Jan 2023 at 18:39:27 +0000, Simon McVittie wrote:
> To minimize regressions, I think we probably want "most" GIR XML files
> to remain in /usr/share, with only the ones that genuinely vary between
> architectures moved into an architecture-specific place. That would make
> their handling similar to C/C++ headers, which similarly are mostly
> placed in an architecture-independent location (/usr/include) but can
> be relocated into an architecture-specific location (/usr/include/TUPLE)
> when necessary.

A reason I particularly think this is that changing the default
installation path for GIR XML would require changes to basically every
source package that ships GIR XML, otherwise it will FTBFS when the
usr/share/gir-1.0 line of its debian/*-dev.install file no longer matches
any files.

If we do this on an opt-in basis, for the minority of source packages
where the GIR XML is genuinely architecture-dependent, then those packages
can adapt (and put back their Multi-Arch: same field) at their own pace,
the same way they can choose to install the minority of C/C++ headers that
are arch-dependent into /usr/include/${tuple} (downstream) or sometimes
into ${libdir} (upstream) to make themselves multiarch co-installable.

Moving even a minority of GIR XML could still trigger regressions in
consumers of GIR XML outside src:gobject-introspection if they were
expecting to be able to find all GIR XML in the $XDG_DATA_DIRS, so it
is definitely post-bookworm material and should happen in experimental
first. I suspect that our friends in Ubuntu would ask me to defer this
change until after their 23.04 branch has stopped imports from Debian.

On Mon, 30 Jan 2023 at 11:20:25 +0100, Helmut Grohne wrote:
> In that forwarded issue, you hint a possible way forward where Debian
> would deviate from upstream. Given upstreams unwillingness to even
> consider this problem combined with this being a real problem affecting
> multiple distribution families, I think moving forward with a
> Debian-specific solution as you depicted would be the best of options
> available. I would expect that adding a Debian-specific location would
> be a patch that rebases easily.

Yes ish, although the search paths are currently inconsistent between
C and Python code and any fixes in that area will make Debian-specific
changes in the same vicinity conflict. I'm trying to get that fixed
upstream, but the CI probably needs to pass again before they will accept
any MR from me (objectionable or not), leading to a significant amount of
yak-shaving involving MSYS2 on Windows which I have no idea how to solve.

Any change in src:gobject-introspection will not solve this on its own in
any case. If we make the Debian-specific search path opt-in, then each
package whose GIR XML is architecture-dependent needs to opt-in. Or,
if we changed the ${girdir} in gobject-introspection-1.0.pc, then each
package with GIR XML would be insta-RC-buggy (FTBFS) until its .install
files were changed (but I think that would be a bad way to manage the
transition, so I'd prefer the divergence from upstream to be opt-in on
a per-package basis).

    smcv