Re: DEP 17: Improve support for directory aliasing in dpkg
On Mon, 8 May 2023 at 09:58, Helmut Grohne <helmut@subdivi.de> wrote:
>
> 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?
Sure, it was just to keep it impersonal. Substitute TC with
"interested party" or so.
> 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).
I think the question of what do we want to support is an important
one, and I care greatly that for this particular endeavour we do not
impose a higher burden on ourselves that would otherwise be expected
in different situations. If expectations are shifting considerably, we
should codify it, so that everyone is held up to the same standards.
> > 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.
If that's the only thing to worry about, then I'm not worried at all!
> > 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.
Well, sure, but once again any backport changes can break in
interesting and novel ways. The simplest of them all is getting the
version wrong so that updates do not work... and yet we have very
little if anything in the way to stop that, no? You can just ignore
Lintian screaming at you and upload...
To me that's just another case to be solved with good documentation
and communication.
Kind regards,
Luca Boccassi
Reply to: