Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
On 2011-08-10 22:44 +0200, Aurelien Jarno wrote:
> On Wed, Aug 10, 2011 at 10:32:27PM +0200, Sven Joachim wrote:
>> On 2011-08-10 22:03 +0200, Aurelien Jarno wrote:
>> >
>> > This is basically what we have in mind, though it has not been tested.
>> > For step 2 and 3, you can call the ELF interpreter directly, that is
>> > "/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 mkdir /lib64".
>>
>> Except for the case where you install the libc on a foreign
>> architecture. Then this might not work.
>>
>
> The goal is to do that only in the preinst of libc0.1/6 (we can't do
> that in the postinst as it would means the files on the filesystem and
> in dpkg are not consistent), and only if /lib64 is a symlink. Given we
> have removed the "Multiarch: same" tag in the libc6 packages of
> architectures having a /lib64 symlink,
You have removed them, but people still might have older libc versions
installed that are Multiarch:same. Like myself in my multiarch
adventure chroot were libc6 is stalled at 2.13-10.
> these systems can't have a foreign coreutils as it would depends on a
> foreign libc which is not installable.
Even if libc6 is no longer Multiarch:same, that does not prevent
installing libc6:amd64 and libc0.1:kfreebsd-amd64 simultaneously,
AFAICS. Now when upgrading you have a 50% chance that the native libc
is unpacked first.
> That's only valid if we ignore the 2 or 3 versions that have been in sid
> with this "Multiarch: same" tag.
Ubuntu has many more versions, and a dpkg that actually supports
multiarch. But for them this may not be such a big problem since only
amd64 and i386 are supported, and people who have enabled multiarch
almost surely run a 64-bit kernel.
Cheers,
Sven
Reply to: