(Dropping the pax bug because I think the potential danger to a user's system is specific to mksh because of the /bin/sh symlink.)
Thorsten Glaser <t...@mirbsd.de> writes: > If I have a link from /bin/sh to a binary from the mksh package, then on > normal upgrades dpkg updates it atomically. Diverting the binary in > /bin/ away will leave the symlink from /bin/sh (which is managed by the > local admin because the dash package ignored two(!) rc bugs regarding > its changed /bin/sh management behaviour, when they broke it, for more > than two releases so the bug got eventually closed so mksh couldn’t > offer package-controlled /bin/sh management that was coordinated with > bash post-lenny) dangling. My summary (just repeating what you said back to you to make sure I understood) is that the problem you're seeing is that dh_movetouser diverts the moved file, which in the case of mksh may mean that /bin/sh is temporarily nonexistent if it is a symlink to mksh. I think there's two angles to this. First, from a Policy standpoint, I don't think this problem is blocking the Policy change. Policy is primarily a set of instructions for how people should create Debian packages in general, and there are often edge cases that it doesn't capture. If someone were packaging a new shell that is a valid /bin/sh target, we would want them to ship that shell in /usr/bin, not in /bin, to ensure that we don't create new potential dpkg database inconsistencies. I think Policy should say as much, even if there are problems with migrating the existing mksh package to that layout. If we need to make an exception for mksh, that's fine; there a lot of ways to do that, many of which don't require writing anything explicitly into Policy. 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? 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? > This is fragile, and the “benefits” are nowhere even near worth it: > /usr-merge per top-level symlinks per CTTE was forced on all systems, so > we got that now, and it is absolutely unnecessary for packages that are > not part of the pseudo-Essential set to move their files because their > implicit Pre-Depends on the Essential set will ensure that the /bin > symlink is already in place so this is a total nōn-issue. Packages that do not have problems such as the /bin/sh symlink should move their files so that we have consistency across the distribution and so that we're not left with variations that we know can cause inconsistency in the dpkg database and all of the related problems that come with that. We still have tool and system representation problems after this move, but they are smaller and more predictable and I believe more tractable to address. 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. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
