On Tue, 2021-07-27 at 16:26:34 +0200, Simon Richter wrote: > On 7/27/21 11:44 AM, Wouter Verhelst wrote: > > A package in the essential set could work around the issue by moving a > > file around and creating a necessary symlink in preinst rather than > > shipping things. The set of Essential packages is small however, and > > most packages can ship a compat symlink. > > In debootstrap (which is the important use case for Essential packages and > their constraints), all Essential packages are unpacked first, and then, > individually, their preinst is run, the files unpacked again (this time from > dpkg), and then we're in normal dpkg land, although in a chroot.
The installation bootstrap is currently "undefined behavior" and it's not specified by policy. The properties of the Essential set do not apply there. See <https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap>. > So the concept of a preinst script for an Essential package is wobbly at > best. Not really. Bootstrapping has always been done with strings and tape. Of course, having to unnecessarily add more maintainer scripts to handle something that dpkg can do perfectly fine on its own, would regress the progress we have been making to make the installation bootstrapping automatable and definable. But that seems less worse than the breakage induced by the merged-/usr-via-aliased-dirs layout. :/ > For debootstrap --foreign, this might be even more complicated. Only a few paths are expected to be hardcoded, nothing that couldn't be special-cased by debootstrap along all other bootstrapping knowledge it contains which would ideally be contained in their respective packages anyway. But this indeed is, having to pile hack over hack from the original broken foundation. > Also, take care when moving shell commands from a shell script: the bash > shell at least keeps a cache of commands to paths so it doesn't have to do a > full path search every time. A shell script that calls > > mv /bin/cp /usr/bin/cp > ln -s ../usr/bin/cp bin/cp > mv /bin/ln /usr/bin/ln > ln -s ../usr/bin/ln bin/ln > > could fall over because it cached the location of "ln" as /bin/ln in the > beginning, then after the move cannot find it anymore. That needs at least a > "hash -d ln". As has been mentioned, this is completely unsafe and does not map to what dpkg would be doing. Regards, Guillem
