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

[Simon McVittie]

On Sat, 23 Dec 2017 at 14:11:38 +0100, Helmut Grohne wrote:
> 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.

As I said, I suspect we don't actually need the triplet-location after
the .pc file has been updated, although I'd have to check in codesearch
to be sure.

>  * Update the .pc files to refer to the /usr/bin instance.

That would consist of altering
debian/patches/61_glib-compile-binaries-path.patch so it only affects
glib-compile-schemas, not glib-compile-resources.

>  * 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 speak for other maintainers, but I suspect that confirming that
your patch was the right thing to do would take about as long as making
a patch myself, so don't bother unless you're in a particular hurry to
get this done. I'll try to get some time for this over Christmas.

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

It's harmless.

gio-querymodules (which is executed alongside glib-compile-schemas)
genuinely does need to be separate for each architecture: it dlopens the
plugins for which it's building a cache. For each instance of GLib you
have installed, either you can execute binaries of that architecture,
or you can't. If you can (let's say it's libglib2.0-0:i386 on your
amd64 system), gio-querymodules runs and everything is fine. If you can't
(let's say it's libglib2.0-0:mips on your amd64 system, and you don't have
qemu-mips set up) then no mips binary is going to run on this machine
*anyway*, so it doesn't matter that the cache that would be loaded by
a mips libgio isn't valid, because nothing is going to load it.

The only harm done by the current approach, apart from the "Exec format
error", is that the "|| true" applied to the invocation of these tools
masks any genuine errors they might encounter. If dpkg had an interface
for "tell me whether I should expect to be able to execute mips binaries",
then we could use that; but it currently doesn't, so the current approach
is the best we can do for gio-querymodules.

Cross-compiling is all about installing foreign architectures' libraries
that you can't actually execute, but library packages' dependencies are
normally about what is necessary to *use* (execute) those libraries, so
it isn't entirely unexpected that there is some weirdness going on there.

glib-compile-schemas works with architecture-independent files (GSettings
schemata) and builds them into a cache. You have some set of GLib
architectures installed, and you have some set of architectures you
can run. If there is a non-empty overlap, then at least one instance
of glib-compile-schemas succeeds, and you have a valid schema cache.
If there is no architecture where you have GLib *and* can run it, then
it doesn't matter that your schema cache is invalid, because nothing is
going to load that cache on your machine.

If gio-querymodules didn't exist, then I'd be more sympathetic towards
the idea that glib-compile-schemas can't be allowed to fail, although I
can't say I'd be entirely comfortable with adding a circular dependency;
but gio-querymodules does exist, so we already have to deal with the
fact that we might be trying to build caches using helper binaries that
we can't actually run, and we might as well take the same approach for
glib-compile-schemas.

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

If GLib bumps SONAME, I promise we'll make the new instance co-installable
with the old. Is that good enough for you?

If somone is going to be a rules lawyer about inserting an extra "0" into
the path, a solution exists; it just seems totally pointless to apply
it in this case, so I'm not going to unless someone forces the issue.

    smcv