Public bug reported:
glib-2.0 declares itself Multi-Arch: same, i.e co-installable. But in
fact this does not work because it cannot be installed on anything other
than the native architecture.
Amongst other things this means that no package build-depending on
glib2.0 can be built (becuase the build-deps don't install).
$apt-get install libglib2.0-0:armel
Setting up libglib2.0-0:armel (2.31.20-0ubuntu2) ...
/var/lib/dpkg/info/libglib2.0-0:armel.postinst: 36:
/var/lib/dpkg/info/libglib2.0-0:armel.postinst:
/usr/lib/arm-linux-gnueabi/glib-2.0/glib-compile-schemas: not found
/var/lib/dpkg/info/libglib2.0-0:armel.postinst: 39:
/var/lib/dpkg/info/libglib2.0-0:armel.postinst:
/usr/lib/arm-linux-gnueabi/glib-2.0/gio-querymodules: not found
dpkg: error processing libglib2.0-0:armel (--configure):
subprocess installed post-installation script returned error exit status 127
The problem is that the postinst contains:
case $trigger in
/usr/share/glib-2.0/schemas)
# This is triggered everytime an application installs a
# GSettings schema
/usr/lib/arm-linux-gnueabi/glib-2.0/glib-compile-schemas
/usr/share/glib-2.0/schemas || true
;;
/usr/lib/arm-linux-gnueabi/gio/modules|/usr/lib/gio/modules)
# This is triggered everytime an application installs a GIO
# module into /usr/lib/arm-linux-gnueabi/gio/modules or the
# backwards-compatible /usr/lib/gio/modules directory
/usr/lib/arm-linux-gnueabi/glib-2.0/gio-querymodules
/usr/lib/arm-linux-gnueabi/gio/modules /usr/lib/gio/modules
/usr/lib/arm-linux-gnueabi/glib-2.0/glib-compile-schemas and
/usr/lib/arm-linux-gnueabi/glib-2.0/gio-querymodules
are both ELF executables and thus not executable on the machine you are
cross-installing onto.
If the output of these commands is arch-independent then a good fix would be to
change these lines to be:
/usr/lib/${DEB_BUILD_MULTIARCH}/glib-2.0/glib-compile-schemas
/usr/lib/${DEB_BUILD_MULTIARCH}/glib-2.0/gio-querymodules
so that the version for the arch being installed-onto always gets run.
However if it is not arch-independent then the postinsts should arrange
to only run these commands when the package is being natively-installed.
If the output for all the versions installed needs to be present then we
need to arrange some way of making this work.
It may be that moving these binaries out into the libglib2.0-bin package
is the right thing to do?
** Affects: glib2.0 (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
glib-2.0 declares itself Multi-Arch: same, i.e co-installable. But in
fact this does not work because it cannot be installed on anything other
than the native architecture.
Amongst other things this means that no package build-depending on
glib2.0 can be built (becuase the build-deps don't install).
$apt-get install libglib2.0-0:armel
Setting up libglib2.0-0:armel (2.31.20-0ubuntu2) ...
/var/lib/dpkg/info/libglib2.0-0:armel.postinst: 36:
/var/lib/dpkg/info/libglib2.0-0:armel.postinst:
/usr/lib/arm-linux-gnueabi/glib-2.0/glib-compile-schemas: not found
/var/lib/dpkg/info/libglib2.0-0:armel.postinst: 39:
/var/lib/dpkg/info/libglib2.0-0:armel.postinst:
/usr/lib/arm-linux-gnueabi/glib-2.0/gio-querymodules: not found
dpkg: error processing libglib2.0-0:armel (--configure):
- subprocess installed post-installation script returned error exit status 127
+ subprocess installed post-installation script returned error exit status 127
The problem is that the postinst contains:
- case $trigger in
- /usr/share/glib-2.0/schemas)
- # This is triggered everytime an application installs a
- # GSettings schema
- /usr/lib/arm-linux-gnueabi/glib-2.0/glib-compile-schemas
/usr/share/glib-2.0/schemas || true
- ;;
+ case $trigger in
+ /usr/share/glib-2.0/schemas)
+ # This is triggered everytime an application installs a
+ # GSettings schema
+ /usr/lib/arm-linux-gnueabi/glib-2.0/glib-compile-schemas
/usr/share/glib-2.0/schemas || true
+ ;;
- /usr/lib/arm-linux-gnueabi/gio/modules|/usr/lib/gio/modules)
- # This is triggered everytime an application installs a GIO
- # module into /usr/lib/arm-linux-gnueabi/gio/modules or the
- # backwards-compatible /usr/lib/gio/modules directory
- /usr/lib/arm-linux-gnueabi/glib-2.0/gio-querymodules
/usr/lib/arm-linux-gnueabi/gio/modules /usr/lib/gio/modules
+ /usr/lib/arm-linux-gnueabi/gio/modules|/usr/lib/gio/modules)
+ # This is triggered everytime an application installs a GIO
+ # module into /usr/lib/arm-linux-gnueabi/gio/modules or the
+ # backwards-compatible /usr/lib/gio/modules directory
+ /usr/lib/arm-linux-gnueabi/glib-2.0/gio-querymodules
/usr/lib/arm-linux-gnueabi/gio/modules /usr/lib/gio/modules
- /usr/lib/arm-linux-gnueabi/glib-2.0/glib-compile-schemas and
- /usr/lib/arm-linux-gnueabi/glib-2.0/gio-querymodules
+ /usr/lib/arm-linux-gnueabi/glib-2.0/glib-compile-schemas and
+ /usr/lib/arm-linux-gnueabi/glib-2.0/gio-querymodules
are both ELF executables and thus not executable on the machine you are
cross-installing onto.
If the output of these commands is arch-independent then a good fix would be
to change these lines to be:
/usr/lib/${DEB_BUILD_MULTIARCH}/glib-2.0/glib-compile-schemas
/usr/lib/${DEB_BUILD_MULTIARCH}/glib-2.0/gio-querymodules
- so that the version for the arch being installed-onto always gets run.
+ so that the version for the arch being installed-onto always gets run.
However if it is not arch-independent then the postinsts should arrange
to only run these commands when the package is being natively-installed.
If the output for all the versions installed needs to be present then we
need to arrange some way of making this work.
- It may be that moving this binaries out into the libglib2.0-bin package
+ It may be that moving these binaries out into the libglib2.0-bin package
is the right thing to do?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/950967
Title:
glib2.0:armel uninstallable on other architectures
Status in “glib2.0” package in Ubuntu:
New
Bug description:
glib-2.0 declares itself Multi-Arch: same, i.e co-installable. But in
fact this does not work because it cannot be installed on anything
other than the native architecture.
Amongst other things this means that no package build-depending on
glib2.0 can be built (becuase the build-deps don't install).
$apt-get install libglib2.0-0:armel
Setting up libglib2.0-0:armel (2.31.20-0ubuntu2) ...
/var/lib/dpkg/info/libglib2.0-0:armel.postinst: 36:
/var/lib/dpkg/info/libglib2.0-0:armel.postinst:
/usr/lib/arm-linux-gnueabi/glib-2.0/glib-compile-schemas: not found
/var/lib/dpkg/info/libglib2.0-0:armel.postinst: 39:
/var/lib/dpkg/info/libglib2.0-0:armel.postinst:
/usr/lib/arm-linux-gnueabi/glib-2.0/gio-querymodules: not found
dpkg: error processing libglib2.0-0:armel (--configure):
subprocess installed post-installation script returned error exit status 127
The problem is that the postinst contains:
case $trigger in
/usr/share/glib-2.0/schemas)
# This is triggered everytime an application installs a
# GSettings schema
/usr/lib/arm-linux-gnueabi/glib-2.0/glib-compile-schemas
/usr/share/glib-2.0/schemas || true
;;
/usr/lib/arm-linux-gnueabi/gio/modules|/usr/lib/gio/modules)
# This is triggered everytime an application installs a GIO
# module into /usr/lib/arm-linux-gnueabi/gio/modules or the
# backwards-compatible /usr/lib/gio/modules directory
/usr/lib/arm-linux-gnueabi/glib-2.0/gio-querymodules
/usr/lib/arm-linux-gnueabi/gio/modules /usr/lib/gio/modules
/usr/lib/arm-linux-gnueabi/glib-2.0/glib-compile-schemas and
/usr/lib/arm-linux-gnueabi/glib-2.0/gio-querymodules
are both ELF executables and thus not executable on the machine you are
cross-installing onto.
If the output of these commands is arch-independent then a good fix would be
to change these lines to be:
/usr/lib/${DEB_BUILD_MULTIARCH}/glib-2.0/glib-compile-schemas
/usr/lib/${DEB_BUILD_MULTIARCH}/glib-2.0/gio-querymodules
so that the version for the arch being installed-onto always gets run.
However if it is not arch-independent then the postinsts should
arrange to only run these commands when the package is being natively-
installed. If the output for all the versions installed needs to be
present then we need to arrange some way of making this work.
It may be that moving these binaries out into the libglib2.0-bin
package is the right thing to do?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/950967/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
