Comment 4 for bug 977966

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