On Tue, 16 May 2023 at 04:22, Russ Allbery <r...@debian.org> wrote: > > > It did look like a veto to me. More importantly, isn't relying on > > passersby to spot alleged harmful changes dangerous, especially for > > undocumented, uncodified and untested use cases, like unspecified and > > vague cross-compatibility requirements? > > I'm honestly boggled. This is a thread on debian-devel, which is > literally how we do architecture vetting in this project. > > I absolutely do not think that we can write down everything of importance > in designing a distribution so that we don't have to have conversations > with other people in the project who have deep expertise when considering > a significant architectural change like changing the PT_INTERP path of > core binaries.
We've almost certainly all encountered limitations in upstream specifications and wondered when it's worth attempting a perceived improvement despite potential friction. If Debian did want/need to change the PT_INTERP path, is there a way to achieve that in both a standards-compliant and also a distro-compatible way? And if there isn't: how would we resolve that? This conversation is already lengthy, and based on recent experience I'm definitely the kind of person who doesn't always read all the details - so I don't know whether it's a good idea for anyone to respond to my message. But I haven't seen anyone discussing or providing a safe migration path. Although tests may not exist publicly in this case, the idea of using tests where possible to catch regressions seems relevant to me. Tests can help people to identify when a compatibility boundary has been reached or overstepped, and, socially, they can provide a clear place to gather discussion if & when they become outdated (particularly if the tests are themselves are provided free and open source). Copying binaries and running them seems like a form of testing, but perhaps we could find better ways.
