Helmut Grohne <hel...@subdivi.de> writes: > 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.
I'm glad that we were able to track this down, and thank you for following up on this to get it fixed. Just to be sure, though, I don't think this is the problem that Thorsten was worried about. My understanding of the problem Thorsten was reporting was slightly different: 1. A user has pointed /bin/sh to mksh, via a local diversion, changed symlink, or whatever other mechanism. The current mksh package, which from dpkg's perspective provides /bin/mksh, is installed. 2. A new version of mksh is uploaded that no longer provides /bin/mksh and does provide /usr/bin/mksh. 3. dpkg unpacks and installs that package. This involves some sequence of operations that, from dpkg's perspective, remove /bin/mksh and install /usr/bin/mksh. However, these are both the same file. My understanding of Thorsten's concern is that there may exist a window during which dpkg would delete /bin/mksh, since it is no longer included in the package, before it installs /usr/bin/mksh, and thus there could be a window where /bin/sh is a broken symlink. If the system crashes in that window, recovery could be annoying. I am unfortunately not very familiar with the ordering guarantees provided by dpkg and with the precise mechanism of dh_movetouser. I did look over the source of the latter and didn't see anything that obviously seemed to handle this case, but I quite likely missed something. This presumably has come up with other packages (libc6, for example), so maybe there's something that makes this safe that I'm not aware of? Maybe the protective diversions also protect against this problem as well as the problem of moved files? I unfortunately failed to spot where the protective diversions were added in dh_movetouser (if that even is the right place to be looking), so I'm fairly sure I'm missing something. > 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. Do we document for users somewhere how to change /bin/sh, as a replacement for the debconf questions? When I was investigating this, I tried to find documentation in the bash and dash packages and was unsuccessful. That's not a Policy question, of course, just an aside, but this sounds somewhat complicated and I'm not sure a user would be able to figure out the new, correct way to change /bin/sh. It sounds like the plan is to cover this in the relesae notes, which is great, but we probably also need ongoing documentation for the future. I'm not sure the best place to put that. Maybe just in README.Debian for whatever package currently provides /bin/sh by default. > 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. Ah, thank you. I had misunderstood some of the previous discussion in this bug. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
