Bug#1029269: gio-2.0.pc references the wrong glib-compile-schemas again

[Simon McVittie]

On Fri, 20 Jan 2023 at 13:10:49 +0100, Helmut Grohne wrote:
> We figured that glib-compile-schemas is an architecture-independent
> tool. Yet, glib installs it for multiple architectures (and I don't
> quite recall why) with /usr/bin/glib-compile-schemas being a symlink to
> the native one.

So that this is written down somewhere: this is because libglib2.0-0 needs
to run (some version of) g-c-s via its triggers. The naive implementation
of this would be to split out g-c-s into its own binary package, but
as well as being a bit of a waste of space (g-c-s is only 64K), that
would introduce a circular dependency, because glib-compile-schemas has
DT_NEEDED on libgio-2.0.so.0 and others:

                   for triggers
    libglib2.0-0 ---------------> glib-compile-schemas
     M-A: same   <---------------   M-A: foreign
                via dpkg-shlibdeps

Splitting up libglib2.0-0 into its separate SONAMEs with their
Policy-compliant package names would not help here, because it's
libgio-2.0.so.0 that makes most sense to "own" the trigger for schemas,
but glib-compile-schemas depends on libgio-2.0.so.0. So the same circular
dependency would exist for libgio-2.0-0.

> Originally, gio-2.0.pc referenced this. Then, a Debian
> patch made it reference the one from libglib2.0-0, which happened to
> break cross compilation of stuff. Then I opened #982213 and we agreed to
> revert that patch. Now the revert has been reverted, but it seems it was
> reverted upstream. Can we revert that again? Would you be able to
> provide more context here than I have?

The upstream change here was 0c087d12 "gio: Optionally install trigger
executables to architecture-specific paths", new in 2.73.3 and written
by me, in order to upstream some of our Debian-specific changes as a
solution to new upstream problems.

Because you have argued that glib-compile-schemas is an
architecture-independent interface, I think if other packages want
to run glib-compile-schemas *at build-time*, and they want to be
cross-compilable, then they ought to be looking for a build-architecture
tool, similar to the way dbus-binding-tool was traditionally handled.

In Meson this would be

    dependency(
        'gio-2.0',
        native: true,
    ).get_variable(
        pkgconfig: 'glib_compile_schemas',
        default_value: 'glib-compile-schemas',
    )

or maybe

    find_program('glib-compile-schemas', native: true)

or some combination of the two (where "native: true" is the part that
gets you a build-architecture dependency lookup, instead of the default
host-architecture).

(One reason why this is annoying to set up is that the upstream build
system of a package that depends on glib-compile-schemas is trying to do
two orthogonal things: it's trying to support having a non-default version
of the tools in a non-default location outside PATH for jhbuild-like
use-cases (which are uninteresting for Debian, but upstreams want to
support this), and it's also trying to deal with cross-compilation. It's
difficult to get both right at the same time without having something like
Meson's dependency(native: true) in your build system.)

I don't think it's really reasonable to expect that querying a
variable from a host-architecture pkg-config file will give you a
build-architecture executable - how would that work in general, when the
host-architecture pkg-config file is common to all build architectures,
and generally specifies its tools by their absolute path? For instance, in
traditional (pre-multiarch) cross-compilation, each architecture of GLib
would have installed its own /usr/${tuple}/bin/glib-compile-schemas, and
querying the ARM pkg-config file would always give you an ARM executable,
never an x86 executable.

However, I'm aware that many build systems don't have as principled
a dividing line between build- and host-architecture dependencies
as Meson does; and for Debian specifically, given the organization
of our GLib packaging, it would be harmless to go back to having
glib_compile_schemas=${bindir}/glib-compile-schemas on all architectures,
which would have the side-effect of it not mattering which architecture
you ask for the appropriate path.

Because this is not a recent regression, I'd prefer to
let the recently-uploaded GLib 2.74.5 migrate to testing
before fixing this, but I agree it would be pragmatic to use
glib_compile_schemas=${bindir}/glib-compile-schemas in bookworm.

This would likely be unappealing upstream, particularly in the short
term, because it relies on the
${bindir}/glib-compile-schemas -> ${libdir}/glib-2.0/glib-compile-schemas
symlink that is created for the primary architecture, but the upstream
build system doesn't guarantee to create that symlink (in particular, it
doesn't do that if the version of Meson is too old for install_symlink()).

It might become upstreamable once their Meson requirement goes up, but
really I think it should be up to the GLib-dependent package (in this
case ibus-unikey) to ask for what it needs, which is a build-architecture
interface.

I also think that it would probably be better if this dependent package
was not running glib-compile-schemas during cross .deb builds at all.
There are two main use-cases for glib-compile-schemas:

- To summarize ${datadir}/glib-2.0/schemas/*.xml into
  ${datadir}/glib-2.0/schemas/gschemas.compiled.
  For a shared directory like /usr/share or when installing into a
  $DESTDIR, this is not an individual package's job - the individual
  package does not "own" /usr/share/glib-2.0/schemas/gschemas.compiled,
  should be letting GLib handle this via triggers, and certainly should
  not be creating a $DESTDIR/usr/share/glib-2.0/schemas/gschemas.compiled
  that will overwrite the one from the system.

- To summarize locally-provided schemas so that they can be used for
  unit tests or similar, via GSETTINGS_SCHEMA_DIR or XDG_DATA_DIRS.
  This is fine for native builds, but should probably not be done for
  cross-builds, because in a "true" cross-build (without qemu-user or
  some similar way to run cross-binaries), you are not going to be able
  to run the tests anyway.

A cross-build with a DESTDIR doesn't seem like it should be doing either
of those?

    smcv