On 2018-01-24 21:05, Javier Serrano Polo wrote: > X-Debbugs-CC: clint@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. At the time the ABI has been written, multiarch was almost not existing. Of course with different information you take different decision. > 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. That may be a mistake, but it ended up being a standard. > > Moving it means > > rebuilding all the packages. > > We do not want that. If you change the program interpreter path, you have no other choice. > > 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. "Fixing" the x86-64 program interpreter path won't magically fix future architecture. Also note that the /libx32/ld-linux-x32.so.2 path is also defined in the same x86-64 ABI document. > 4. Using /lib was the multiarch way. I don't think you should use the past there. It was not at the time it has been decided. > 5. Specs, standards and laws can eventually be amended. Why you don't start by that then? Just right a new ABI document for the x86-64 CPU and create a new architecture from it. Then this architecture can be supported by Debian. > 6. Another challenge to accomplish something supposedly impossible. That still do not explain how moving the program interpreter would work. > 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? No it clearly doesn't work the extra work of maintaining such a build profile. In addition it will causes confusion, violate the debian policy and the build profile specification. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net
Attachment:
signature.asc
Description: PGP signature