On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote: > The loader is still available via the old path, so external/third > party/local/other software works unchanged. This should negatively > only affect our 1st party packages, when running on a non-merged > distro. > And are _all_ our packages really 100% compatible with other distros > at all? Are they even supposed to be?
People build things on Debian that are not Debian packages. People compile binaries on Debian, and expect them to work on any system that has sufficiently new libraries. This is *not* about Debian packages failing to work on other distributions; this is about *software compiled on Debian* faliing to work in other environments. If you build a dynamically linked binary that only depends on glibc, you can expect it to be reasonably portable, to any system that uses glibc and has a sufficiently new version. Debian stable is, in fact, one of the common environments people use to compile binaries for distribution. > So, what I am asking is, what actual, real difference does it make if, > by default (and with an override available for example), packages > built on Debian for Debian record the ld path to point to its (actual) > location on Debian, via say a compiler spec file that is injected in a > deb build? Making binaries built *on* Debian different than binaries built *for* Debian would introduce a needless additional source of complexity, compared to just compiling code the same way in both cases. To frame this in different terms: consider that one of the major goals of systemd has been to harmonize across distributions and eliminate needless variations that don't serve much actual purpose (e.g. variations in config file paths for the same config file). Consider how much effort systemd went to work with distributions, understand and deal with the *important* variations, and try to convince them to abandon the *unimportant* variations. Now imagine if someone came along and said "let's patch systemd to put unit files in /purple/; it'll work with everything in our distribution". Or, imagine if someone said "let's inject an argument to gzip, only for building the .gz files sihpped in our packages of course, to modify the gzip header and remove a few of the extraneous additional fields; it'll be fine, because we've patched our gzip to parse it" The x86-64 ABI is set. Feel free to make the case to the next architecture designer that their new ABI should have the dynamic linker in `/usr/lib`. That would *not* have the same downsides, as long as everyone agrees on a path. - Josh Triplett
