I'm interested in packaging (or helping to package) several programs and libraries related to OpenGL, (such as apitrace, vogl, fips, and waffle).
For each of these packages I have a question about best practices related to supporting 32-bit libraries and binaries within a 64-bit system. Imagine a package (waffle-utils, say) that installs a program (/usr/bin/wflinfo, say) that reports some information about a library (libGL.so, say) against which it is linked. So on either an -i386 or an -amd64 system, a user could install the native package, run the program, and query the native library. But now imagine a user with an -amd64 system that has an alternate -i386 library provided by a multilibs package (such as libgl1-mesa-glx:i386). It would be useful for such a user to have both the native 64-bit program and a 32-bit program available at the same time, (to be able to query either library). For this use case, would I make a separate waffle-utils-32 package targeted for -amd64 but containing a 32-bit /usr/bin/wflinfo-32 that, other than the name, would be identical to /usr/bin/wflinfo as contained in waffle-utils:i386? There are similar issues with apitrace, vogl, and fips where a 64-bit wrapper program will be invoked on a target OpenGL application. Then, depending on whether the target program is 32- or 64-bit, the wrapper will need to load a 32- or 64-bit library provided by some dependent package. Can someone point me to some existing packages that have had to deal with similar issues so that I might imitate similar packaging solutions? I know that the old ia32-libs package obviously involved some -i386 binaries in packages targeting -amd64. But I'd be more interested in seeing some precedents in modern packages after the multilibs transition. Thanks in advance for any ideas. -Carl -- carl.d.wo...@intel.com
pgpequ9YYawA4.pgp
Description: PGP signature
