Here's a cautionary heads up on the transition from ordinary to multilib Debian.
I run Debian Wheezy amd64. Some 32 bit applications are installed, and somehow I came to a point where ia32libs wanted to update and transition me to a multilib setup. I'm still trying to figure out if that happened because I accidentally had sid enabled, or not, but I decided to go ahead and see what happens. The big block of 32bit support libraries from ia32-libs is replaced by a lot fo i386 packages.
It has been a little interesting to rebuild some local packages, I think most of that will work itself out.
But today I found about a serious problem I want to warn any/everybody about. The multilib packages will replace files from /usr/lib with files that go into /usr/lib/x86_64-linux-gnu or /usr/lib/i386-linux-gnu.
In the packaging, there are commands that one should insert so that the install of the multilib package causes the removal of files from /usr/lib when the new are installed. However, some packages malfunction, and so you are left with the old shared library files. I was having a devil of a time building some packages because the build system was finding libraries that I thought had been removed in /usr/lib.
I used a handy Debian tool "cruft" to survey the situation, and here are some of the "abandoned" library files that were left in /usr/lib:
libanl-2.11.2.so
libanl.so.1
libBrokenLocale-2.11.2.so
libBrokenLocale.so.1
libcidn-2.11.2.so
libcidn.so.1
libcrypt-2.11.2.so
libcrypt.so.1
libgcc_s.so.1
libmemusage.so
libnss_compat-2.11.2.so
libnss_compat.so.2
libnss_dns-2.11.2.so
libnss_dns.so.2
libnss_files-2.11.2.so
libnss_files.so.2
libnss_hesiod-2.11.2.so
libnss_hesiod.so.2
libnss_nis-2.11.2.so
libnss_nisplus-2.11.2.so
libnss_nisplus.so.2
libnss_nis.so.2
libpcprofile.so
libresolv-2.11.2.so
libresolv.so.2
libSegFault.so
libthread_db-1.0.so
libthread_db.so.1
Here's what goes wrong. The linker notices shared files in /lib or /usr/lib, but it can't find shlib dependency information on those in /var/ hierarchy (because that hierarchy now shows they are in /usr/lib/x86_64-linux-gnu.
If you try to compile a package, you will recognize the problem if the error says
error: no dependency information found for /lib/libnsl.so.1
and it is pointing to a file that is in there, but
$ dpkg -S /lib/libnsl.so.1
is not owned by a package, and then you notice that there is a newer version of libnsl.so in /usr/lib/x86_64-linux-gnu.
I'm pretty sure this is right, but I can't rule out the possibility that some other thing that happened in apt-get or synaptic caused this. I also found a big chunk of python numpy stuff was "orphaned" by package updates.
As I mentioned, the cruft package from Debian was a big help in finding the problem. All I did was install the package, then
$ cd /tmp
$ sudo /usr/sbin/cruft -d /lib -r report-lib
$ sudo /usr/sbin/cruft -d /usr/lib -r report-usrlib
that cranks out the reports that show whether files are missing or not valid members of deb packages.
As I mentioned, the cruft package from Debian was a big help in finding the problem. All I did was install the package, then
$ cd /tmp
$ sudo /usr/sbin/cruft -d /lib -r report-lib
$ sudo /usr/sbin/cruft -d /usr/lib -r report-usrlib
that cranks out the reports that show whether files are missing or not valid members of deb packages.
