Hi Thorsten, On Tue, Aug 06, 2024 at 09:58:44PM +0000, Thorsten Glaser wrote: > I’m veto’ing this.
I see that Russ is kindly handling this. Thanks to him. > >This relies on undefined behaviour in dpkg. Guillem is working on > >improving metadata tracking and accurately tracking metadata will make > >this break. It is not enough to rely on the implicit essential > >dependency. > > Then the tracking could be aware of this and DTRT. Aliasing is unsupported in dpkg and has never been. We are currently working in an undefined-behaviour area and the main goal of the /usr-move transition is to get us into defined-behaviour waters. While I appreciate that metadata tracking could eventually support aliasing use cases, that is not planned for the initial implementation as aliasing never has been supported. > And that works how? By diverting the files away temporarily, > leaving users with a dangling /bin/sh symlink during the pak‐ > kage upgrade which almost certainly will lead to a failing > upgrade which will leave the user with a hosed system. dh_movetousr does not manage any dpkg diversions. All that it does is move the files inside the .deb's data.tar. Despite you having expressed quite some words on the prospective failure case at hand, I am difficulties turning this into a reproducer. Can you try to sketch a possible interaction with dpkg and a hypothetically /usr-moved mksh package that would lead into such a failure? Note that I already understood the issue about a local dpkg diversion of /bin/sh being rendered ineffective (DEP17 P3). This is a problem that already affects mksh right now regardless of these bugs and that I intend to handle separately regardless of these matters. It is not something that would cause a failed upgrade though and therefore I am expecting that you are referring to a different problem here. > As an issue reporter, there comes a time when you are of the > opinion that what you opened is a bug, but the maintainer dis‐ > agrees. This is such a case. This is not a bug in mksh, and > even if it were, the fix would lead to broken users’ systems > and therefore isn’t worth it. Alternative ways to fix this, > #2 in dpkg and #1 is currently a nōn-issue (and if dpkg’s new > metadata tracking is being written, it can be written to account > for this, as I have the right of having been here first). In case of disagreement of what constitutes a bug we have two arbitration mechanisms. For one thing, the release team defines what is considered a release-critical bug and they can override the decision of a package maintainer. I expect the release team to back up my view that this is a release-critical bug in mksh and pax given that the release team agreed to my transition bug. The other route is escalating to the CTTE. Given earlier rulings of the CTTE, I expect a likely outcome even though I would abstain from voting if this were to come onto the CTTE. I again ask you to reopen the bugs and suggest that we can skip involving those teams that way. As the discussion of the matter is ongoing and new insights are gained, I do not expect you to fix the bugs soon. We should find a resolution before the transition freeze though. You may also express the ongoing discussion by adding a moreinfo tag. The meaning of the bugs in this case is expressing the need for change without having agreed on what change that is. Thanks for considering Helmut
