I'm reporting this here because I expect other users might run into this problem with the mulitlib migration and Debian developers might need to know about it.
Last week I posted here about a Wheezy problem in the transition to multilib. I had added the i386 arch and upgraded with apt-get. After that, some Debian packages could be rebuilt, but the installer refused, complaining about dependency on libc6-amd64. While banging on that system to try to work it out, I did something that completely broke the system. I mean, I completely broke it, nothing would run, not "ls" nor "shutdown". I completely foobared the C library. Booh. So I made a clean install of Wheezy Beta 4 from disk. And now comparing what I had before, with what I have now, I think I have a theory. Before, on the Wheezy system that was being updated by apt-get, I had this collection of libc6 packages: $ 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 And the error I was seeing, after building a package on my old system, was $ 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). Note the dependency on "libc6-amd64" was created automatically, by the Dbian packaging scripts. I did not put that in. One responder to my previous question said that version 2.7 was never even released, thus I must have installed a C library manually. Not true, I'd never do that. Now, On the clean system, after adding the arch=i386, my libc6 collection is 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-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 ii libc6-i686:i386 2.13-37 i386 Embedded GNU C Library: Shared libraries [i686 optimized] On this new system, I can rebuild the blt package and it does install. What's the difference? Now the blt.substvars file does not include libc6-amd64, but just libc6. See? $ cat blt.substvars shlibs:Depends=libc6 (>= 2.7), libx11-6, tcl8.5 (>= 8.5.0), tk8.5 (>= 8.5.0) misc:Depends= So my theory is that somewhere in the packaging magic, there was a package called libc6-amd64, I had it, other packages depended on it. But in the multilib evolution, libc6-amd should have been removed and replaced by something else, say libc6:amd64. However, dependency hell prevented me from removing libc6-amd64, and while it was still there, it was confusing builds and installs. Do you agree with this theory? 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/CAErODj8oVNsyfCKUvK1paJNrOF1TB9tXRraV-j_fo7Oua1QE=g...@mail.gmail.com
