On Sun, 14 May 2023 at 22:37, Josh Triplett <j...@joshtriplett.org> wrote: > > 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.
Why would "software compiled on Debian" fail to work in other environments? Well, there are many reasons actually, people invented containers/flatpaks/snaps exactly for that reason. But nothing do with anything discussed here though, as far as I can tell? > 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. "sufficiently new version" is doing a lot of work there. We have shlibs dependencies for a reason. In fact, the most common environment used to distribute binaries is the EOL Ubuntu 16.04, slowly switching to the soon-to-be-EOL 18.04. glibc is not forward-compatible, new symbols are added all the time and are used all the time, and you don't jump on a brand new distribution to do that kind of work, that would be self-defeating. > > 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. That's not how it works today already. There are several significant differences between just running "gcc sources.c" and building a package via debhelper on a buildd, they are not the same thing at all, and they haven't been since forever, there are dozens of compiler/linker options that the Debian package build environment sets. Or will you now also ask the distribution to rollback multiarch, hardening, SOURCE_DATE_EPOCH, -ffile-prefix-map and all the other reproducibility options, and so on? These and many more are all "needless additional sources of complexity, compared to just compiling code the same way" too. Because guess what, there are people who couldn't possibly care less about multiarch/security/reproducibility/etc, and there will also be a subset of users who considers a subset of those compiler options "needless". So are you going to push to have all of that reverted? And also are you going to propose a Policy change that forbids adding any new compiler/linker option to the package build process? > 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". Pretty sure the Nix folks are already doing pretty much that. And if it works for their case, all the power to them. > 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" Not really related, archives are _intended_ to be opened anywhere for any reason. Do you have any actual related use case that would no longer work? Because that would be the easiest and most convincing counter-factual that could be provided. > 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. In practice it is not, though. There are other distributions that change PT_INTERP for their own purposes, they've already been listed in this thread. And I am still not hearing any concrete, factual use case that would be impaired by such a change. I'm beginning to seriously think there aren't any? Is that really the case? Kind regards, Luca Boccassi
