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

[Simon McVittie]

On Fri, 20 Jan 2023 at 20:45:06 +0100, Helmut Grohne wrote:
> I had not questions the use of glib-compile-schemas. Thank you for doing
> it. Your arguments look reasonable to me. As far as I can see,
> ibus-unikey does not install a .compiled schema, so the call to
> glib-compile-schemas is probably redundant and questionable.

ibus-unikey does install
/usr/share/glib-2.0/schemas/org.freedesktop.ibus.engine.unikey.gschema.xml,
so in the absence of triggers, yes it would have to run
glib-compile-schemas. The function of g-c-s is to collect all the
*.gschema.xml (and possibly some less common files describing enums),
and summarize them in a single mmap'able binary file that doesn't require
spending time, malloc/free cycles and readdir calls on parsing multiple
XML files at runtime.

However, in a well-integrated distribution, dpkg triggers or equivalent
should be responsible for doing that - not individual packages.

A pattern I've often seen in GNOME is to run glib-compile-schemas as a
post-install hook if and only if $DESTDIR is empty or unset, so that when
compiling a dpkg/rpm/etc. package with something like

    ./configure --prefix=/usr               # or CMake/Meson equivalent
    DESTDIR=$(pwd)/debian/tmp make install

we wouldn't run glib-compile-schemas (on the assumption that the package
manager will take responsibility), and would maybe show a warning "you
need to run glib-compile-schemas later" instead; but when doing a local
installation that is installed directly into place with something like

    ./configure --prefix=$HOME/jhbuild      # or CMake/Meson equivalent
    make install

or

    ./configure --prefix=/opt/gnome         # or CMake/Meson equivalent
    make
    sudo make install

each package would re-run glib-compile-schemas for convenience. This
mirrors how ldconfig tends to work, and I think this would be the ideal
thing for ibus-unikey to do as well.

Looking at
https://sources.debian.org/src/ibus-unikey/0.7.0~beta1-1/cmake/GSettings.cmake/
it seems that the build should be specifying -DGSETTINGS_COMPILE=OFF in
debian/rules, as a way to let the dpkg triggers take responsibility for
doing this later.

The other common reason to run glib-compile-schemas is so that unit tests
can find schemas in a temporary ($builddir) location at build-time, and
I think this should only be done if the build-time tests are actually going
to be run. In Debian terms, looking at
https://sources.debian.org/src/ibus-unikey/0.7.0~beta1-1/cmake/GSettings.cmake/
I think the nocheck build profile should be specifying
-DGSETTINGS_COMPILE_IN_PLACE=OFF (or maybe this particular package should
just have -DGSETTINGS_COMPILE_IN_PLACE=OFF unconditionally, I don't know
whether it even has build-time tests that want the schemas).

> Your
> request to disable such calls seems very reasonable to me. Would you
> prefer me trying to generally remove calls to glib-compile-schemas over
> changing glib2.0?

In the medium to long term, yes I would.

> After all of this insightful conversation, I see three ways of moving
> forward:
> 
> a. Accept the dependency cycle and make the per-architecture paths
>    reference the one in /usr/bin.
> b. Change gio-2.0.pc to reference the /usr/bin one.
> c. Change upstream project to avoid unnecessary calls to
>    glib-compile-schemas.
> 
> Do you concur that these are the options on the table? Which of them do
> you prefer? I admit that c looks appealing as it means least work for
> you and some work for me while a or b shifts that burden to you. ;)

I'd be OK with doing (b) as Debian downstream delta in the short term if
it would help, but in the medium to long term, I think the right way is
(c) (combined with Meson "native: true" or equivalent tool discovery if
feasible, but I realise that's probably only viable in Meson-world).

> >                    for triggers
> >     libglib2.0-0 ---------------> glib-compile-schemas
> >      M-A: same   <---------------   M-A: foreign
> >                 via dpkg-shlibdeps
> 
> Is such a circular dependency actually a problem?

I would say yes if it can be avoided. Any time apt breaks a cycle, it's
doing something that's out-of-spec for the guarantees that we normally
use to reason about what is safe to assume.

Circular dependencies also make it harder to clean up unused packages,
because each package in the circle prevents the next one round the circle
from being diagnosed as unused...

> A popular example is libdevmapper1.02.1 <-> dmsetup

... and as it happens, I ran into this exact example last week while
cleaning up cruft that had accumulated in one of the development chroots I
use for my day job (I think it got there via a Recommends chain involving
cryptsetup and systemd, but removing those was not sufficient to hint
aptitude into also removing the dmsetup/libdevmapper cycle).

> > 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.
> 
> Outside the meson ecosystem, dealing with two pkg-config is very rare.
> When looking beyond Debian, the expectation typically is a different
> one: When cross building, you are expected to build packages (such as
> glib2.0) specifically for a combination of build and host architecture
> such that the one .pc file references the mixture of tools.

How would you go about building GLib like that? Let's say for the sake
of a concrete example that your cross-compilation is the popular "ARM on
x86" scenario (host=ARM, build=x86). I can't think of any way you could
configure GLib to produce a pkg-config file that lists an ARM shared
library and an x86 glib-compile-schemas, either in its current Meson
build system or in its older Autotools build - the only way I can see
would be to rely on either the Debian-specific separation of one source
package into multiple binary packages, or installing in just the right
order so that one build overwrites another.

If we were still in Autotools-world, the way I would always have done
this would be to force use of a specific x86 version of compile-time
executable tools, overriding what would ordinarily have been picked up
from pkg-config, like for example if glib-compile-schemas is the only
native tool you needed, you might invoke:

    ./configure --build=x86_64-etc --host=arm-etc \
        PKG_CONFIG=arm-etc-pkg-config \
        GLIB_COMPILE_SCHEMAS=/usr/bin/glib-compile-schemas

As long as the dependent package uses either AC_CHECK_PROG or
PKG_CHECK_VAR to find glib-compile-schemas, it's straightforward to do
that, because both macros always let you specify the "result variable"
as an AC_ARG_VAR configure parameter.

Or in CMake you'd have to hope the dependent project offers an appropriate
-D option, either to specify the right glib-compile-schemas or to turn
off unnecessary use of it.

    smcv