I suspect this is another multiarch growing pains problem. I'm on Debian Wheezy with multiarch enabled. I'm trying to understand a packaging problem. I'm getting shlibs inserted in the debian/package.substvars file and I can't understand why.
For example, lets rebuild the blt package. $ apt-get source blt $ cd blt-2.4z $ dpkg-buildpackage -rfakeroot The package builds, but when I try to install it, the system thinks I don't have libc6-amd new enough. Like so: $ sudo dpkg -i blt_2.4z-4.2_amd64.deb [sudo] password for pauljohn: (Reading database ... 393464 files and directories currently installed.) Preparing to replace blt 2.4z-4.2 (using blt_2.4z-4.2_amd64.deb) ... Unpacking replacement blt ... dpkg: dependency problems prevent configuration of blt: blt depends on libc6-amd64 (>= 2.7). dpkg: error processing blt (--install): dependency problems - leaving unconfigured Processing triggers for doc-base ... Processing 1 changed doc-base file... Registering documents with scrollkeeper... Processing triggers for man-db ... Errors were encountered while processing: blt However, I do have libc6-amd MUCH NEWER than 2.7 (I'm multilib): $ dpkg -l | grep libc6 ii libc6:amd64 2.13-37 amd64 Embedded GNU C Library: Shared libraries ii libc6:i386 2.13-37 i386 Embedded GNU C Library: Shared libraries ii libc6-amd64 2.13-37 i386 Embedded GNU C Library: 64bit Shared libraries for AMD64 ii libc6-dbg:amd64 2.13-37 amd64 Embedded GNU C Library: detached debugging symbols ii libc6-dev:amd64 2.13-37 amd64 Embedded GNU C Library: Development Libraries and Header Files ii libc6-dev-i386 2.13-37 amd64 Embedded GNU C Library: 32-bit development libraries for AMD64 ii libc6-i386 2.13-37 amd64 Embedded GNU C Library: 32-bit shared libraries for AMD64 rc libc6-i686:i386 2.13-37 i386 Embedded GNU C Library: Shared libraries [i686 optimized] ii libc6-prof:amd64 2.13-37 amd64 Embedded GNU C Library: Profiling Libraries Partly I'm curious about that particular problem with blt, but more generally, I'm curious about how/why the substvars file gets thusly: $ cat debian/blt.substvars shlibs:Depends=libc6-amd64 (>= 2.7), libx11-6, tcl8.5 (>= 8.5.0) | tcl8.4 (>= 8.4.16), tk8.5 (>= 8.5.0) | tk8.4 (>= 8.4.16) misc:Depends= Why >= 2.7? Why libc6-amd64. AFAICT, it is not for the so files: $ cat debian/blt/DEBIAN/shlibs libBLTlite.2.4 8.5 blt (>= 2.4z-4.1) libBLT.2.4 8.4 blt (>= 2.4z-4.1) libBLT.2.4 8.5 blt (>= 2.4z-4.1) libBLTlite.2.4 8.4 blt (>= 2.4z-4.1) $ ldd debian/blt/usr/lib/libBLT.2.4.so.8.5 linux-vdso.so.1 => (0x00007fff6dbff000) libtk8.5.so.0 => /usr/lib64/libtk8.5.so.0 (0x00007f88ca40e000) libtcl8.5.so.0 => /usr/lib64/libtcl8.5.so.0 (0x00007f88ca0ee000) libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f88c9db2000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f88c9b30000) libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f88c9917000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f88c9713000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f88c9389000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f88c916c000) libXss.so.1 => /usr/lib/x86_64-linux-gnu/libXss.so.1 (0x00007f88c8f69000) libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f88c8d56000) libXft.so.2 => /usr/lib/x86_64-linux-gnu/libXft.so.2 (0x00007f88c8b40000) libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f88c8909000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f88c86e9000) /lib64/ld-linux-x86-64.so.2 (0x00007f88caaab000) libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f88c8449000) libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f88c8240000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f88c8028000) libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f88c7dfe000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f88c7bfb000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f88c79f5000) $ ldd debian/blt/usr/lib/libBLTlite.2.4.so.8.5 linux-vdso.so.1 => (0x00007fffb09ff000) libtcl8.5.so.0 => /usr/lib64/libtcl8.5.so.0 (0x00007f3bc2354000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3bc20d2000) libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f3bc1eba000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3bc1cb6000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3bc192b000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3bc170f000) /lib64/ld-linux-x86-64.so.2 (0x00007f3bc28dd000) To create the shlibs dependency, I think dpkg-shlibdeps is reading files in /var/lib/dpkg/info. I can't find any "2.7" associated with libc6-amd in there. And, if libc6-amd is really the i386 version of the C library supplied on mutiarch systems, I don't really understand why the package is trying to depend on it at all. pj -- Paul E. Johnson Professor, Political Science Assoc. Director 1541 Lilac Lane, Room 504 Center for Research Methods University of Kansas University of Kansas http://pj.freefaculty.org http://quant.ku.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caerodj981oec3fr-9wpbbt1bh0j5nb49j0y+tom9trxomtg...@mail.gmail.com