Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems
On Wed, Aug 10, 2011 at 10:32:27PM +0200, Sven Joachim wrote:
> On 2011-08-10 22:03 +0200, Aurelien Jarno wrote:
>
> > On Wed, Aug 10, 2011 at 08:35:39PM +0200, Sven Joachim wrote:
> >>
> >> I'll have a look at it in the next few days if nobody beats me to it.
> >> Just to confirm that my ideas were the same as yours, AFAICS the
> >> following needs to be done in the preinst (on amd64), if /lib64 is a
> >> symlink:
> >>
> >> 1) remove /lib64
> >> 2) create /lib64 directory
> >> 3) symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to /lib64/ld-linux-x86-64.so.2
> >>
> >> 2) and 3) are a bit difficult after the path to the ELF interpreter has
> >> just disappeared. I guess you still want to stick to shell nonetheless
> >> (as opposed to doing these steps in perl, say) ?
> >>
> >
> > 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, these systems can't have a
foreign coreutils as it would depends on a foreign libc which is not
installable.
That's only valid if we ignore the 2 or 3 versions that have been in sid
with this "Multiarch: same" tag.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: