Re: DEP 17: Improve support for directory aliasing in dpkg
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
Reply to: