This patch needs work, similar to the one for orbit2.
- libbonobo2-0 ships a file in a directory /usr/lib/bonobo/monikers/, which needs to be architecture qualified. No problem, this becomes /usr/lib/$arch/bonobo/monikers/libmoniker_std_2.so.
- the resolution of the moniker file happens via /usr/lib/bonobo/servers/Bonobo_Moniker_std.server. Since it now references a file path that's architecture-dependent, the file needs to be moved to an architecture-qualified directory. However, this file is shipped in libbonobo2-common, which is an Architecture: all package. So this file needs at the same time to be in a multi-arch: foreign, architecture: any package - probably by moving it to libbonobo2-0, since that's the package containing the module itself.
- Since there are other packages that install files to /usr/lib/bonobo/servers/, libbonobo needs to retain support for this directory as a fallback, similar to what's implemented in orbit2.
Hi Tom,
This patch needs work, similar to the one for orbit2.
- libbonobo2-0 ships a file in a directory /usr/lib/ bonobo/ monikers/ , which needs to be architecture qualified. No problem, this becomes /usr/lib/ $arch/bonobo/ monikers/ libmoniker_ std_2.so. bonobo/ servers/ Bonobo_ Moniker_ std.server. Since it now references a file path that's architecture- dependent, the file needs to be moved to an architecture- qualified directory. However, this file is shipped in libbonobo2-common, which is an Architecture: all package. So this file needs at the same time to be in a multi-arch: foreign, architecture: any package - probably by moving it to libbonobo2-0, since that's the package containing the module itself. bonobo/ servers/ , libbonobo needs to retain support for this directory as a fallback, similar to what's implemented in orbit2.
- the resolution of the moniker file happens via /usr/lib/
- Since there are other packages that install files to /usr/lib/