Hi Joshannes,
On Wed, Oct 05, 2022 at 02:35:30PM +0200, Johannes Schauer Marin Rodrigues
wrote:
> To enable creating a foreign architecture Debian chroot during the early
> bootstrap of a new Debian architecture, maintainer scripts and utilities
> called by maintainer scripts of packages in the essential and
> build-essential set, should support operating on a custom chroot directory.
> This is to avoid running any of the foreign architecture utilities from the
> chroot, because those cannot be executed during the early bootstrapping
> phase of a new architecture. Instead, by avoiding the chroot() call,
> utilities from the outside should operate on the chroot path given via the
> `DPKG_ROOT` environment variable. This environment variable is set but
> empty during normal package installations. If the `DPKG_ROOT` environment
> variable is not empty, then this indicates to the maintainer scripts and
> the
> tools it executes, that a chroot is being built as part of an early
> architecture bootstrap and all operations should be performed in the chroot
> path given by the contents of the `DPKG_ROOT` environment variable. In that
> case, the maintainer script should not modify anything outside the chroot
> directory.
Thank you for writing this.
> I refrained from using "must" because we promised maintainers that they would
> not need to do the work themselves but will get patches sent from us. We do
> not
> want to force work on maintainers by making it an RC bug if they do not
> support
> DPKG_ROOT.
>
> Helmut, what do you think?
I think this text is already quite good. I am yet wondering about the
scope of support that we mention here.
1. You write that we want essential + build-essential. In practice, we
also want things such as apt or systemd. I am wondering whether we
should rephrase this in a less specific way that leaves open some
packages beyond the mentioned set. Vagueness can be avoided by
explaining the purpose: We target packages that are relevant to
setting up an initial build daemon.
2. We should likely mention that package upgrade and removal paths can
freely ignore DPKG_ROOT. Maintainer scripts can assume that when
DPKG_ROOT is in effect, it will be an initial installation. Something
along this would have helped Michael in determining whether his
recent changes to init script handling would affect DPKG_ROOT.
Let me try to extend your text:
To enable creating a foreign architecture Debian chroot during the early
bootstrap of a new Debian architecture, maintainer scripts and utilities
called by maintainer scripts of packages relevant to setting up a
build daemon, should support operating on a custom chroot directory.
[... keep rest of the text unchanged ...]
Support for `DPKG_ROOT` in code that handles package upgrades or
package removal is not needed.
Helmut
