[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: multiarch/bi-arch status (ETA) question

On Tue, 5 Jul 2005, Lennart Sorensen wrote:

The main objection is to change locations of files in a way that is
incompatible with existing software on linux.

But it is not incompatible unless you remove the links - and then you are no longer following the proposal.

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

As I understand it, /usr/lib is a symlink/hardlink/bindmount to /usr/lib/i386-linux, not the other way around.

can't be a symlink to /usr/lib/i386-linux after all.  So if programs on

I don't understand. Why not?

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?

But they won't. I must have expressed myself quite badly to have been misunderstood on this so much.

I am not saying that one starts multiarch and immediately pretends its finished. Only that one can start, without breaking anything... so why not start?

Why not make /usr/lib/i386-linux and make the links? New packages would eventually follow the new standard directly; old ones would be gradually ported over. The whole time, you are still pure64, or ia32. At some point, when dpkg/apt and the other infrastructure work is finished, and a usable subset of packages is compliant, then you can switch to "being" multiarch. In the meantime, you manage everything just as you do now.

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.

Right. But that's why you make the links, and then start on the work.

Later, when the work is complete, we can support multiple architectures, and until then, we have lost nothing - everything works as it does now.

Reply to: