Comment 5 for bug 977966

On Mon, Apr 23, 2012 at 09:59:48AM -0000, Martin Pitt wrote:
> Does liborbit gracefully handle the situation when you e. g. install
> libgnome-mag2:i386 on an amd64 machine, and thus
> /usr/lib/orbit-2.0/GNOME_Magnifier_module.so is an i386 library?

Good question. The relevant loader code is:

                paths = ORBit_get_typelib_paths ();

                for (i = 0; paths && paths [i]; i++) {
                        fname = g_strconcat (
                                paths [i], G_DIR_SEPARATOR_S, libname, "_module", NULL);

                        if ((loaded = load_module (fname, libname)))
                                break;

                        else {
                                g_free (fname);
                                fname = NULL;
                        }
                }

load_module() returns false if g_module_open() fails, which will be true if
either the file doesn't exist or if it's of the wrong architecture (since
g_module_open() is a wrapper around dlopen()).

So a wrong-architecture module on the path should have no impact

> If so (gvfs handles that corresponding case just fine), it's all ok. If
> not, I'd rather we convert the other packages to the new multi-arch path,
> too.

If this would cause problems, those should be fixed in their own right as
part of the update, to ensure that a partial upgrade of orbit2 without the
plugin packages doesn't cause problems. Partial upgrades in SRUs are much
more likely to hit users than partial upgrades between releases.

I've regression-tested the module loading by manually installing an i386
version of Bonobo.so to /usr/lib/x86_64-linux-gnu/orbit-2.0/Bonobo.so on my
system, shadowing /usr/lib/orbit-2.0/Bonobo.so, and launching quodlibet, a
gnome2 app that loads Bonobo.so on my system. Strace confirms that with the
new liborbit2, /usr/lib/x86_64-linux-gnu/orbit-2.0/Bonobo.so is opened and
then rejected in favor of /usr/lib/orbit-2.0/Bonobo.so.

An application that wants to load a module from /usr/lib/orbit-2.0/ will of
course not be able to do so if it's of the wrong architecture; but the risk
of this leading to a regression is minimal, because currently only packages
of the native architecture will be installed (for both consumers of
liborbit2 and plugins). *After* this SRU it will be possible for users to
mix architectures in a way that's not usable, but that still requires wrong
configuration on the part of the user.