XPost: linux.debian.policy

Helmut Grohne <helmut@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 (rra@debian.org) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)