Re: DEP 17: Improve support for directory aliasing in dpkg
On Wed, 26 Apr 2023 at 10:11, Simon Richter <sjr@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
Reply to: