Bug#885019: reconsider placement of glib-compile-resources

[Simon McVittie]

On Fri, 22 Dec 2017 at 23:03:35 +0100, Helmut Grohne wrote:
> Having this tool both on an
> architecture-dependent path and in an m-a:foreign package seems wrong to
> me: Either the tool has architecture-dependent behaviour, then
> libglib2.0-bin shouldn't symlink it, or it doesn't and then it shouldn't
> live on an architecture-dependent path.

As far as I can tell from skim-reading its source code, this tool has
non-architecture-dependent output, so it should live in libglib2.0-bin or
libglib2.0-dev-bin (optionally with symlinks in all the arch-dependent
places shipped in for libglib2.0-{0,dev} for backwards compat, if there
might be packages that hard-code this Debianism rather than using either
PATH or pkg-config). I suspect the arch-dependent symlinks wouldn't be
needed, assuming we stop patching the .pc file to refer to them.

> As far as I can tell,
> glib-compile-resources is a development tool. Yet it is placed into the
> shared library package. Why does it have to be in the shared library in
> the first place?

I can't explain that. It seems to be in the same category as
gdbus-codegen: a tool to be run by other packages at build-time.
Some of those packages are architecture-independent and might not
"naturally" pull in GLib development headers (gnome-sound-recorder is
a good example), but making those build-depend on libglib2.0-dev-bin
wouldn't be disastrous IMO.

The maintainer who packaged it that way might have mixed it up with
the older glib-compile-schemas, which genuinely does need to be run on
non-developer systems (it's used in maintainer scripts).

> Worse, the path is independent of the soname of the library, so any
> prospective soname bump (that will never happen) would cause a file
> conflict. On paper, this is a violation of Debian policy section 8.2.

glib-compile-schemas and gio-querymodules have the same theoretical policy
violation, but they have to be included in libglib2.0-0 because if they
weren't, there would be a circular dependency between libglib2.0-0 and
whatever package they were shipped in. (Those tools need GLib libraries,
and the GLib libraries maintain registries of schemas and modules that
need to run those tools in their triggers.)

If GLib upstream ever bumped the SONAME, that would be such a massively
disruptive change that in practice they would also have to bump the
ABI version (the 2.0 in glib2.0) to make the old and new libraries
fully parallel-installable, so this is not going to be a problem in
reality. If someone was being enough of a rules lawyer about it, the
GLib maintainers could move glib-compile-schemas and gio-querymodules
from /usr/lib/TUPLE/glib-2.0 to /usr/lib/TUPLE/glib-2.0-0, creating a new
subdirectory alongside glib-2.0 for zero practical benefit; but there
seems no point, because if for some reason the highly unlikely SONAME
bump happened, the new glib-2.0-1 directory could easily be created at
that time.

    smcv