X-Debbugs-CC: cl...@debian.org El dc 24 de 01 de 2018 a les 18:26 +0100, Aurelien Jarno va escriure: > The dynamic linker path is part of the > x86-64 ABI and is present in all ELF executables.
I am aware that the original specification has that quirk, but it was made without multiarch in mind. Would you choose /lib64 if you could decide? I would not. I think that if there is a will this can be fixed. Other architectures are easy to see. For instance, m68k and powerpc conflict with /lib/ld.so.1. amd64's interpreter does not conflict, but all interpreters should be under /lib. I see /lib64 as a mistake that can be fixed. > Moving it means > rebuilding all the packages. We do not want that. > Could you please explain it how it works and what would be the use case? I will explain the workings later, but let us discuss the use case. This scenario has been running since 2010. Why did I drop /lib64? 1. A cleaner root directory. 2. A consistent root directory among architectures. 3. To avoid future architectures to have their own root directories, such as /libx32. 4. Using /lib was the multiarch way. 5. Specs, standards and laws can eventually be amended. 6. Another challenge to accomplish something supposedly impossible. It is all about transitions. You may think this use case is not worth the interim compatibility measures, but it is my use case and I have seen other people dislike /lib64. So, is this case worth a build profile at least?
smime.p7s
Description: S/MIME cryptographic signature
