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 <hert...@debian.org> ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
