On Wed, 26 Apr 2023 at 10:11, Simon Richter <s...@debian.org> wrote: > > Hi, > > On Tue, Apr 25, 2023 at 09:07:28PM +0200, Helmut Grohne wrote: > > > This and /bin/sh is the kind of files I'd consider important. And then > > upon thinking further it became more and more difficult for me to make > > sense of the objection. On a merged system, we can just move that file > > to its canonical location without having any trouble even with an > > unmodified dpkg. So from my pov, the question about important files can > > be disregarded. I hope Simon Richter agrees. > > Yes, the relevant code at > > https://github.com/guillemj/dpkg/blob/main/src/main/unpack.c#L749 > > already handles moving a file inside the same package, and that has > existed for some time, that's why I use two packages for the PoC. > > I have not looked for more issues beyond that, so there might be others > lurking in the depths of this code. > > What I'm mostly concerned about (read: have not verified either way) > with /lib/ld.so and /bin/sh is what happens when dpkg learns of /bin and > /lib as symlinks -- because right now, the symlinks created by usrmerge > are protected by the rule that if dpkg expects a directory and finds a > symlink, that is fine because that is obviously an action taken by the > admin. > > But if dpkg sees a package containing these as symlinks, then this is > entered into the dpkg database, and subject to conflict resolution, and > for that, a separate rule exists that directory-symlink conflicts are > resolved in favour of the directory, so the interaction between a newer > base-files packages shipping /lib as a symlink and an older or > third-party package containing /lib as a directory (e.g. a kernel > package from a hosting provider) could overwrite the /lib symlink. > > It might be possible to avoid that by never shipping /lib as a symlink > and always creating it externally, but I still think that's kind of > wobbly.
IMHO we should not ship the top-level symlinks in a package. The reason for that is to allow the use case where /usr is a separate vendor partition and / is either a luks volume or a tmpfs, and thus the top-level symlinks are ephemeral and re-created on boot on the fly. If they were part of a package, that would get awkward to say the least. I really would like to move toward the direction of having exclusively /usr and /etc shipped in data.tar, and everything else created locally as needed, and that includes files in /. Kind regards, Luca Boccassi