On Thu, 8 Jun 2023 at 09:46, Raphael Hertzog <hert...@debian.org> wrote: > > 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.
Just a note that we can always change debootstrap via bookworm-p-u, we've already done so in the past for this, so there's no requirement to wait an extra release. Kind regards, Luca Boccassi
