On Mon, May 08, 2023 at 02:07:08AM +0100, Luca Boccassi wrote: > I can see we don't agree on this matter, of course, that is clear. And > I hope we can find common ground. But let me provocatively ask this > first: is the same rule going to be enforced for all other changes > that happen in the project that might affect external packages? If > anybody points out past changes, recent or less recent, that caused > issues for third party packages, will the TC ask for those changes to > be reverted or otherwise modified accordingly? Will a change to Policy > be proposed that spells out that third party packages cannot ever be > broken, no matter what they do, and must always work?
I'm not sure about the TC's role in this. For the record, I am doing all of the analysis (and design work) in this thread without a TC hat. I also cannot comment on what the TC is going to rule this matter. Can we leave that aside or formally file it there if you see a need? I agree that what we support is vague at best and we can readily see from earlier conflicts that this is a recurring matter. We still disagree over how much maintainers should support sysvinit. I've also quite recently failed at properly preparing a transition (non-essential adduser) and while we could write about it in release-notes, what is going to happen is that we'll revert it for bookworm and then I can retry properly. You may also have noticed that my analysis of possible problems in this thread very much reasons about packages shipped in Debian releases. I would actually like to call external packages and local diversions unsupported, but I was rightfully criticised that this is falling short. So no, I cannot tell you where the boundary of our support is. I initially assumed it to be closer to where you paint it and am now trying to adapt to meet the expectations of others. For instance, I've also reached out to DSA and inquired on their use. While I haven't found local diversions or local statoverrides in dsa-puppet.git, it seems that a number of external packages ship files in /sbin or /lib (including udev rules and systemd units). > The more pre-depends, the more constraints we put on apt. I do not > have a specific scenario in mind as we don't even have a full set of > changes to look at, but it seems clear to me it will have _some_ > effect, no? We've been there with multiarch-support and my experience with that suggests that the primary effect is increasing the size of Packages files. Though given that you are obviously worried here, I suppose more research is warranted. > Sure that's a legitimate concern, however, wouldn't it fall into the > "needs special handling" bucket? It is a case where the file is moving > both in location and package, so it is covered by the blank statement > "either don't do that or implement the required workaround via > diversion/conflict/etc". What am I missing? You are missing the distribution of responsibility. Quite commonly, backports are performed by someone else than the package maintainer. Yet, an uncoordinated backport can now render the package in unstable rc-buggy. > But the more I think about it, the more I am convinced that the > default option working best for Debian is the one that matches the > project's choice of a filesystem layout. After all, this is > configurable in the toolchain for a reason. > And the vast majority of the rest of the world has long since finished > this transition, so I struggle to think where software built with this > default wouldn't work. Bullseye will be oldoldstable at that point, > and even that was default merged for new installations, and really old > ones (oldoldoldoldstable at that point? I lost count) will be long > EOL. I suppose they could still be around unmaintained, but who uses a > toolchain from 8 years in the future to build software for an EOL > distribution 8 years in the past? Normally it's the other way around, > as even glibc adds new symbols and is not forward compatible. This seems somewhat convincing to me. Would you reach out to toolchain maintainers to discuss this as an early change after the release of bookworm? > On the ELF interpreter, as long as we can reasonably ensure it works, > I do believe we should switch it, regardless of what we do with the > symlinks, how we ship/add/build/package/create/manage them, as a > desired final state. Again, we should make the default in Debian work > for Debian. And given the default for Debian from Bookworm onward is > that the loader is in /usr/lib/, it seems perfectly reasonable to me > that it software built for Debian and shipped in Debian should look > there for it. I suppose that we've been confusing the different approaches here. The question of what links base-files should contain mostly arises if you start from the assumption that we do not modify the ELF interpreter location. Once changing its (and /bin/sh's) location, the question of how to install those symlinks can indeed be done in base-files.postinst or at some other place where dpkg doesn't have to know much about it indeed. Would you agree to examine the approach where we don't modify the ELF interpreter location in parallel as a backup plan? Helmut