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

[Helmut Grohne]

Hi Simon,

thank you for taking the time.

On Fri, Dec 22, 2017 at 11:08:58PM +0000, Simon McVittie wrote:
> 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.

Matches my evaluation. Let me try to turn that into actions:
 * move glib-compile-resources to libglib2.0-dev-bin (in /usr/bin)
 * Turn the triplet-location into a symlink.
 * Update the .pc files to refer to the /usr/bin instance.
 * Ensure tight enough dependencies and work out breaks/replaces.

Do you agree with this plan? I'd try to come up with a patch for that.

> 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.

I think breaking rdeps now (from a release cycle pov) is fairly
reasonable. Also shrinking libglib2.0-0 should be welcome as it has
relatively high popcon.

> 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).

I admit that I am bewildered by the frequent "Exec format error" from
glib-compile-schemas that I see when configuring glib-ish packages for
foreign architectures. I am yet unsure whether I should be more
concerned about the "Exec format error" or the fact the postinst
succeeds anyway. Something is very wrong here as well, but thus far I
couldn't connect it to any cross build failures so maybe it really is
harmless.

> 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.)

Well, I suggested relaxing the policy wording to a "should", but a
non-representative survey on #debian-devel seemed in favour of keeping
it a "must". I'm unsure where to draw the line. Soname bumps of things
like glib or glibc are extremely unlikely, yet the policy wording
requires taking care of this possibility with a "must" language. From my
pov, it seems that policy is out of touch with reality. At the same
time, we know that packages do violate this and with every other
transition we see how painful it is to have shared libraries with
different sonames conflict. So general relaxing likely is not the best
answer.

I also contend that while circular dependencies are discouraged
multiarch occasionally makes them unavoidable. Sometimes a library
depends on a tool and the tool depends on the library. While the library
should be in a M-A:same package, the tool usually should be in a
M-A:foreign package. The only way to achieve this is a circular
dependency. Essentially, the design of multiarch incurs such 1-cycles.

Helmut