Michał Górny <mgo...@gentoo.org> wrote: > > 'No mainstream' as you claim it doesn't mean it's fine to invent yet > another completely incompatible solution.
As I understand, the compatibility with Debian might be increased (keeping /lib32), at the cost of slightly decreasing the compatibility with Red Hat (concerning 32bit emulation). So depending on the use case, it might as well be more compatible. >> in _all_ /lib* directories > > This is not true. You are right, I had made a stupid mistake. (I forgot that I still have the symlink lib->lib64 so that of course I should not have wondered why all ld-* existed in both libs...) > the linker uses /lib path independently of how multilib is done > on the system. I am not sure whether I understand what you mean. Do you mean that practically sys-libs/binutils or sys-libs/glibc have hardcoded /lib -> 32bit /lib64 -> 64bit (concerning ld-*) unless one patches it out? In this case you are right that there is an upstream to follow. In this case I wonder why Debian decided to patch out this upstream decision to support /lib32. > The 32-bit proprietary binaries use exactly /lib which is the main > reason for the switch. I thought the main reason for the switch is to avoid the merging of /lib and /lib64 which in bug 506276 led to problems for debugging. For this reason I am afraid that now merging /lib and /lib32 might again lead to a similar type of problems. I am aware that exactly the cited problem is now mitigated, because this time the merging does not happen over a symlink. But anyway, it seems unnatural when "curing" from a merge to decide to merge something else.
