- Package:
- libglib2.0-0t64
- Source:
- libglib2.0-0t64
- Description:
- GLib library of C routines
- Submitter:
- Daniel Richard G.
- Date:
- 2024-08-27 19:15:02 UTC
- Severity:
- normal
I am installing this package as a cross-compilation dependency for an
amd64-to-armhf build. In the install log, I see
Setting up libglib2.0-0t64:armhf (2.82.0-1) ...
/var/lib/dpkg/info/libglib2.0-0t64:armhf.postinst: 37: /usr/lib/arm-linux-gnueabihf/glib-2.0/glib-compile-schemas: Exec format error
/var/lib/dpkg/info/libglib2.0-0t64:armhf.postinst: 38: /usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules: Exec format error
The postinst script should check that the package is being installed on
a compatible architecture before running these (binary) programs.
Control: severity -1 minor
Yes. This is harmless, and installation continues.
How? We cannot know whether running a foreign-architecture executable
is possible on the current architecture (perhaps natively, perhaps via
qemu-user-binfmt or box86 or similar) other than by trying it.
We could ship a trivial executable (the equivalent of /bin/true) for the
host architecture, try to run that, and if it succeeds, proceed with
running the executables that we actually wanted to run... but that seems
equivalent to what already happens, just with extra steps?
These programs need to be run if and only if other programs of the same
architecture will be run. For example, if you had qemu-user-binfmt enabling
you to run armhf programs, then armhf programs that require a GIO module
would not work correctly if the armhf gio-querymodules had not been run.
smcv
If running the actual binary is the only viable way of checking
whether or not it is usable, then do so explicitly with a trivial
invocation, e.g.
if ! /usr/lib/x86_64-linux-gnu/glib-2.0/glib-compile-schemas --version >/dev/null 2>&1
then
# System architecture is probably incompatible
echo 'Cannot run glib-compile-schemas, skipping update'
exit 0
fi
(Even better would be to detect the package_arch != system_arch
condition and print out a more specific error message, but I don't know
the right way of getting that info in a postinst script.)
That at least avoids showing an error message to the user that is, to
all appearances, not anticipated/handled by the package installation.