(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.
++ 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-archifica tion.
There are a number of packages which ship libraries in the old directory:
$ zgrep usr/lib/orbit-2.0 /tmp/Contents- i386.gz debug/usr/ lib/orbit- 2.0/Accessibili ty_LoginHelper_ module. so universe/ libdevel/ libatspi- dbg debug/usr/ lib/orbit- 2.0/Accessibili ty_module. so universe/ libdevel/ libatspi- dbg orbit-2. 0/Bonobo_ module. so libs/libbonobo2-0 orbit-2. 0/GNOME_ Magnifier_ module. so universe/ libs/libgnome- mag2 orbit-2. 0/GNOME_ Speech_ module. so universe/ libs/libgnome- speech7
usr/lib/
usr/lib/
usr/lib/
usr/lib/
usr/lib/
(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.