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