Re: multiarch/bi-arch status (ETA) question
On Tue, Jul 05, 2005 at 03:21:41PM -0400, David Wood wrote:
> I'm just trying to understand what people's objections to multiarch are. I
> didn't understand what Hugo said in answer to that. I meant that it
> sounded like his answers (the problems he brought up) were things that
> multiarch would fix, not problems with multiarch itself.
The main objection is to change locations of files in a way that is
incompatible with existing software on linux.
> Would they not work properly with the symlink in place?
is /usr/lib/i386-linux a symlink back to /usr/lib or what? /usr/lib
can't be a symlink to /usr/lib/i386-linux after all. So if programs on
i386 look for things in /usr/lib and programs on amd64 look in /usr/lib,
which one gets to keep the location and which one MUST move?
Sure you can recode ld-linux.so to look in /lib/<arch> and
/usr/lib/<arch> which I have seen done years ago on solaris systems
using various path lookup tricks and such.
> And if that failed (is this really possible?), why not use a bind mount?
> Or a hard link? (Well, maybe you don't like hard links, but without
> multiarch, bind mounts in chroots are a fact of life anyway.)
The problem is you have multiple architectures that all want the same
filenames in the same location. bind mounts and symlinks won't solve
that unfortunately. Changing the ld loader might, but even then
anything else that has a hardcoded path needs fixing.
After all if a library package called libx provides the file
/usr/lib/libx.so.0.1 and you decide multiarch should move that to
/usr/lib/i386-linux/libx.so.0.1 then you ahve changed the path (and
ld-linux needs to be changed to be different that it currently is on
i386 systems). If you left it in /usr/lib then you can't install an
amd64 version of libx since it too wants /usr/lib/libx.so.0.1
> I feel a little crazy here. Is there something really basic I'm missing?
>
> What do you mean not compatible? With the linkage of the legacy directory
> to the new one, where would the incompatibility come from?
Both amd64 and i386 programs want the legacy location. They can't both
be symlinks. And if you place the arch stuff as a subdir of the
original location it can't be a bind mount or symlink at all.
> A library would work unmodified in the old location, and then over time it
> can be modified to work in the new one.
But is the old location file going to be i386 or amd64 architecture?
Some other distributions have made their amd64 stuff use /usr/lib64/
instead, which we are compatible with using a symlink, but it's
considered a rather unclean solution by many.
Len Sorensen
Reply to: