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