Quoting Russ Allbery (2021-11-20 18:22:27) > * Create a new essential package that contains these symlinks and that > needs to be unpacked before any binaries are executed in the target file > system. This has many of the advantages and drawbacks of the approach > of putting the symlinks in base-files, but may make it easier to handle > the upgrade problem. Ideally an upgrade would then involve installing > usrmerge, letting it run, and then installing this new essential package > so that it takes over ownership of those symlinks. > > This still feels kind of complex and messy to me, but maybe less so. > > * Create the symlinks directly in the bootstrapping script. In other > words, after unpacking base-files, the bootstrapping script would > directly create the required symlinks in the target file system, before > unpacking any other package. > > This has the obvious drawback of moving things outside the packaging > system and creating a new special case that every bootstrapping script > needs to be aware of (and I know we have at least four or five that > would need modifications). It has the advantage that the usrmerge > symlinks are now not in the dpkg database and thus not subject to > rewriting, and therefore won't need to be special-cased. However, that > comes with the obvious disadvantage that they're not in the dpkg > database, so for instance dpkg -S /lib wouldn't find that symlink unless > it was added as some sort of dpkg-query special case (which doesn't seem > like a great idea). > > The advantage of this approach is that it closely mimicks what's already > happening now with the usrmerge package, and for which we therefore have > a lot of existing experience. Please don't. Since 2014 it is possible to create a Debian chroot without taking care of the unpack order and without running any special setup beforehand that cannot be put into apt or dpkg itself (like creating /var/lib/dpkg/info which is not needed anymore since dpkg 1.20.0). One of my biggest motivations in writing mmdebstrap was to get rid of all the quirks that currently live in debootstrap, move them into apt and dpkg so that we end up with a declarative bootstrap process that is driven by the package contents, their metadata and maintainer scripts but does not need magic from the outside other than standardized interfaces. Requiring the merged-/usr setup to be done by the bootstrap script would be a step backwards. Think about the following points: * you create a Debian unstable chroot using snapshot.d.o -- now you have to somewhere put code that identifies that this is a chroot from the past and that has to decide whether that chroot should be merged-/usr or not. If merged-/usr setup was living somewhere in the Essential:yes package set the chroots would be created the right way automatically * same for derivatives -- now every bootstrap script has to learn which derivative defaults to merged-/usr, which ones do not and when they switched * we somehow need to convert installations of users that only run testing or unstable but never do full stable installation to merged-/usr -- one way to do that is to let one package in the Essential:yes set drive the conversion at which point the bootstrap script doesn't need to know about merged-/usr because the Essential:yes set knows how to set it up * think about it from a software engineering point of view: Debian as a component based software distribution should move specific functionality into its packages and global functionality into declarative metadata. Just as we are currently trying to reduce maintainer scripts and replace them by declarative approaches, we should also try to reduce the magic in our bootstrap scripts and move it either to our package managers or replace them by declarative solutions. We have been moving into the right direction during the last few years as apt and dpkg have picked up functionality I had earlier put into mmdebstrap (thanks a lot to guillem, DonKult and juliank for picking up my patches or writing the functionality themselves). It would mean a step backwards if all bootstrap scripts would have to carry the setup_merged_usr() function from debootstrap and then decide by some $magic when this function should be executed or not. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature