Hi Thorsten and Russ, thanks for dissecting the disagreement. Your reply helped me better understand what Thorsten probably sees as a problem.
On Tue, Aug 06, 2024 at 05:23:35PM -0700, Russ Allbery wrote: > Second, you believe the existing migration strategy will not work safely > for mksh because of the potential /bin/sh symlink. Helmut, do you > disagree with this? I'm not sure I'm clear on the precise point of > disagreement: is the argument a factual disagreement about the behavior of > the tools and the upgrade process, or an argument about acceptable risk? I was looking at this too narrowly from a mksh-perspective only and I still think that the addition of dh_movetousr to mksh does not worsen the situation on the mksh side. What I didn't see as clearly earlier is that the way people tend to use mksh is by adding a local diversion for /bin/sh and such a diversion is subject to DEP17 problems and in particular, it is rendered ineffective by dash/0.5.12-9, which moves /bin/sh to /usr/bin/sh. Say I have a bookworm system with mksh and /bin/sh locally diverted. Now I upgrade dash to trixie. In that process, dpkg will honour the diversion during deletion and then see that no diversion affects the new location /usr/bin/sh happily overwriting /usr/bin/sh (and via aliasing /bin/sh) breaking the user's earlier choice to link /bin/sh to lksh. > Both bash and dash have already done this migration; how did they handle > this problem? Presumably they are at least as widely used as /bin/sh as > mksh is, and I don't recall this breaking people's systems. Perhaps I > missed those problems? bash and dash earlier had a mechanism based on package-issued diversions and debconf. I managed to remove this mechanism before the release of bookworm and now the only supported way of changing /bin/sh is local diversions. Indeed, bash and dash did not handle this at all as we deemed messing with local diversions to be too much risk of getting the user's intention wrong. Rather, we will be extending the release-notes and add a section on local diversions asking users to duplicate them before upgrading. Given that diverting /bin/sh is a more common use case, I think it is fair to add a check to dash.preinst for /bin/sh being diverted and /usr/bin/sh not and in that case abort the upgrade giving users the chance to fix their system before moving forward. I will be filing a bug with a patch for dash later (hopefully today). So thanks to your interaction, I now see how there is a problem for mksh, but it is not introduced nor worsened by using dh_movetousr in mksh. > I don't think this is really open for discussion at the Policy Editor > level since my understanding is that the CTTE has decided that this is how > we're going to do the transition. In the case where this approach risks > harm to the user's system, obviously that is something that needs to be > analyzed and appropriately addressed, but in the typical case, no, the > files in the packages should move so that we get to the more predictable > and easier-to-reason-about end state that was the goal of the migration > fix adopted by the CTTE. I don't think the CTTE has actually issued a ruling on DEP17 or /usr-move short of repealing the moratorium in order to enable moving forward. The initial DEP17 as I proposed it suggested leaving all files in place and enabling dpkg to understand the aliasing. However, that is not the solution that consensus emerged around. I then adopted and pursued the /usr-move path that I perceived as reaching most agreement. There are two occasions where this could be seen as having been vetted. One is elaborate discussions on d-devel with consensus summaries that have not been objected to. The other is a transition bug that has been acknowledged by the release team. In any case, I do not think we can use the CTTE to back up my proposed policy change. Helmut
