Please transition orbit2 to multi-arch

There is some progress in the upstream debian bug, a patch was submitted but needs some modifications.

I've build-tested all reverse-build-dependencies of orbit2 in the precise archive with the exception of libreoffice, and have seen no problems with any of them.

++ g_ptr_array_add (paths, g_strdup ("/usr/lib/orbit-2.0"));

This backwards compat patch raises some further questions, as it's a change beyond standard multi-archification.

There are a number of packages which ship libraries in the old directory:

$ zgrep usr/lib/orbit-2.0 /tmp/Contents-i386.gz
usr/lib/debug/usr/lib/orbit-2.0/Accessibility_LoginHelper_module.so universe/libdevel/libatspi-dbg
usr/lib/debug/usr/lib/orbit-2.0/Accessibility_module.so universe/libdevel/libatspi-dbg
usr/lib/orbit-2.0/Bonobo_module.so libs/libbonobo2-0
usr/lib/orbit-2.0/GNOME_Magnifier_module.so universe/libs/libgnome-mag2
usr/lib/orbit-2.0/GNOME_Speech_module.so universe/libs/libgnome-speech7

(I filtered out the files from orbit2 itself.) These should be tested during verification.

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? 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.

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.

I agree, it's not a problem of this SRU that an amd64 liborbit can't load :i386 extensions in /usr/lib/orbit-2.0/. Thanks for the careful testing!

Hello Tom, or anyone else affected,

Accepted orbit2 into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

The package in proposed installs ok and allows both arch's to be installed. Fixed for me.

This bug was fixed in the package orbit2 - 1:2.14.19-0.1ubuntu1

---------------
orbit2 (1:2.14.19-0.1ubuntu1) precise-proposed; urgency=low

  [ Riku Voipio ]
  * Multiarchize. Closes: #641615.

  [ Steve Langasek ]
  * Remove .la files from the package, as they're no longer needed.
  * debian/patches/pre-multiarch-compatibility.patch: Support pre-
    multiarch directory as a compatibility fallback. Closes: #641615,
    LP: #977966.
 -- Steve Langasek <email address hidden> Fri, 20 Apr 2012 23:34:47 +0000