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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
