hypothesis about the trouble I had with libc6 and multilib: extraneous libc6-amd64
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
Reply to: