[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)



Hi Raphaël,

On Thu, Jun 08, 2023 at 10:46:24AM +0200, Raphael Hertzog wrote:
> In the same spirit, I'd like to throw an idea... could we decide that
> base-files is the first package to be configured as part of the bootstrap
> protocol and change base-files maintainer's scripts into statically linked
> executables so that they can work even if we don't have the library loader
> on the ABI-compliant path?

Thanks for putting effort into this questions. You already figured that
this poses a problem to dpkg calling the maintainer script. Let me add
two further observations to further understand the solution space here.

dpkg has a --root flag and can be called externally. This is something
mmdebstrap already uses in some modes. That way, we avoid the issue you
presented for dpkg itself. Unfortunately, we cannot assume presence of
dpkg outside the chroot as debootstrap supports running on non-Debian
systems, so the --root flag doesn't actually help us here.

The other aspect is that maintainer scripts that are not interpreted
break chrootless foreign architecture bootstrap as the
base-files.preinst would be an executable that the processor cannot
execute.

In a vague reply to the other messages as well: I repeatedly got the
feedback that I have not sufficiently exploited the solution space. I
hear you. My lack of replies here shall indicate that I'm not done.

I have a vague sketch that seems to kinda work out for everything, but
maybe it still has some problems that I don't see yet. Let me summarize
it even though this very much is unfinished. Given my earlier
categorization of the solution space, this is a category 2 solution
addressing many of the problems mentioned there.

Update debootstrap (in bookworm and unstable) to create the symbolic
links after unpacking rather than before while still doing it before
running any maintainer scripts. This enables us to ship the symbolic
links in some data.tar while keeping bootstraps of bookworm and earlier
working as before.

Add a new package usrmerge-support (or whatever). It is a bit similar to
multiarch-support: It must not have any dependencies or
pre-dependencies. It will not have files, but maintainer scripts. Those
scripts set up protective diversions on behalf of base-files for the
symbolic links that cause aliasing. Then base-files will issue a
Pre-Depends on usrmerge-support (but not yet ship symlinks). I initially
thought, this could be part of usr-is-merged, but then base-files would
pull that and standard mmdebstrap would no longer pull usrmerge and
break. So it really needs to be a separate package. Anyway, once we have
protective diversions, we can move files without risking that dpkg
deletes the symbolic links.

Then we can actually perform that move of files to their canonical
locations except for a small set of locations including dash, bash,
libc6, and util-linux (maybe not exhaustive). [There is a lot of missing
detail about non-bootstrap aspects here.]

Once all essential packages (but the exceptions) have no files left in
aliased locations, we can upload base-files adding the symlinks together
with the packages previously kept unmodified in one dinstall. Before
that dinstall, things will continue to work normally. The protective
diversions will not affect unpacking, because dpkg only performs exact
matches on diversions. After that dinstall, base-files will create the
symlinks and things will hopefully work (because the patched debootstrap
only creates them after the initial unpack).

This still is a lot of wishful thinking. I've prototyped parts of this,
but not the entire story. I'm pretty sure it'll not work out as written
here, but maybe some adaption of it will unless insurmountable issues
pop up. For instance, debootstrap --variant=buildd (which currently
implies --no-merged-usr) will need a second thought.

You may now tell me why this is utter nonsense and why it cannot work at
all. Thanks.

Helmut


Reply to: