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

[Raphael Hertzog <hertzog@debian.org>]

Hi,

On Wed, 17 May 2023, Helmut Grohne wrote:
> For completeness sake, there is one more entry in category 3: We can run
> the dynamic loader from its canonical location explicitly, so we'd
> modify maintainer scripts to start with:
> 
>     #!/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /usr/bin/sh
> 
> This would only affect preinst scripts participating in bootstrap and
> we'd not bother with changing PT_INTERP in the toolchain nor in
> packages. Unfortunately, this completely breaks the DPKG_ROOT work and
> with that, I see no viable entries in category 3 for moving forward.
> 
> Moving on to category 4 feels rather obvious, especially because work
> has been done there in debootstrap. The approach in debootstrap however
> is one that I see as a dead end, because it causes us to maintain this
> code multiple times. It's the number of derivatives times the number of
> bootstrap tools and that doesn't scale.
> 
> Category 4 is wider though and we also have other prior art at
> https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap. In particular,
> making architecture bootstrap become chrootless would likely be a
> generic solution to this and other problems.  However, any change needs
> to propagate to a stable release in all bootstrapping tools.  Therefore
> we cannot reasonably finish the transition before forky.  This makes
> category 4 rather unattractive in a short term, but still worth pursuing
> in a long term.

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?

And creating the required symlinks would be done by those (standalone)
maintainer scripts...

I don't know if we already have some rule/invariant in the configuration
order of the unpacked packages, but I doubt so.

> Having ruled out categories 3 and 4 maybe category 2 would be good?  We
> could just ship those symlinks in base-files and be done, right?
> Unfortunately, we pass -k to tar in debootstrap, so when it extracts
> base-files and tries to unpack the bin -> usr/bin symlink, it sees that
> oh no, there already is a symlink at bin (as debootstrap placed it
> there) and thus fails. So in order to make this work, we also have to
> modify debootstrap (and thus are in a combination of category 3 and 4).

So when we will have fixed this, and waited for a release cycle, we can
get rid of the statically compiled maintainer scripts and simply ship the
symlinks in base-files.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog <hertzog@debian.org>
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋    The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄⠀⠀⠀⠀   Debian Long Term Support: https://deb.li/LTS