Source: debian-policy Version: 4.6.1.1 Severity: wishlist User: debian-d...@lists.debian.org Usertags: dpkg-root-support X-Debbugs-Cc: jo...@debian.org, debian-cr...@lists.debian.org
Hi, in [1] Russ asked us to submit a policy bug about DPKG_ROOT so here it goes. :) [1] https://lists.debian.org/874jx3yq8s....@hope.eyrie.org Here is one description of DPKG_ROOT from the dpkg man page: DPKG_ROOT Defined by dpkg on the maintainer script environment to indicate which installation to act on (since dpkg 1.18.5). The value is intended to be prepended to any path maintainer scripts operate on. During normal operation, this variable is empty. When installing packages into a different instdir, dpkg normally invokes maintainer scripts using chroot(2) and leaves this variable empty, but if --force-script-chrootless is specified then the chroot(2) call is skipped and instdir is non-empty. In practice this means that if (and only if) dpkg is called with --root=X --force-script-chrootless then all maintainer scripts will be called with the DPKG_ROOT variable set to X. Why is this useful? In the very early days of a new architecture, emulation support is either not available at all or too buggy to be useful for any practical purposes. After having cross-built the initial package set, these packages need to be installed to create a chroot that can then be used to continue building packages natively on the new architecture, completing the early bootstrap process. But creating that chroot requires package maintainer scripts to be run but we cannot emulate the new architecture to run any of its binaries. By installing packages with --force-script-chrootless, maintainer scripts are called without being inside the chroot and thus they will call the native binaries from the outside. To be able to know the chroot directory they are supposed to operate on, the DPKG_ROOT variable is set to the chroot directory. In practice, this means that if a maintainer script ran this before: chmod root:root "/path/to/file" Then it now has to run chmod root:root "$DPKG_ROOT/path/to/file" More information about DPKG_ROOT can be found here: * https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap#Proposal:_chrootless_maintscripts * https://debconf22.debconf.org/talks/23-what-is-dpkg_root-and-what-is-it-not/ * https://lists.debian.org/166289720850.2390.3729551131862514967@localhost I think there is no problem with letting policy describe what the DPKG_ROOT variable being set to a non-empty string means for a maintainer script. There is also no problem in documenting what the whole point of this exercise is. But there are also a lot of open questions for which I do not have any answers yet: * where to document this? Other variables set for maintainer scripts like DPKG_MAINTSCRIPT_PACKAGE or DPKG_MAINTSCRIPT_ARCH do not seem to be documented either even though (according to codesearch.d.n) they are used in hundreds of places * what about scope? The Essential:yes and build-essential package set are certainly a *must*. We need these to start building natively on a new architecture. But do we need more than those? Having apt would be handy but not strictly necessary (dpkg -i can always be used instead). Having an init system would be handy but not strictly necessary (can always boot with init=/bin/bash). * what can maintainer scripts supporting DPKG_ROOT expect from the system on the outside? Are its package versions the same as the system inside the chroot? Is it even Debian? Right now we do all our tests such that the system on the outside is identical to the one we want to create the chroot for except that it is of the native architecture. But should such a restriction be placed in policy? * what about upgrades? We only want to create a chroot and some of our patches are made much simpler because we ignore upgrades. If newer package versions are required, the bootstrapper can just create a new chroot without upgrading anything. Thank you for your consideration! cheers, josch
