Bug#1020323: debian-policy: document DPKG_ROOT

[Helmut Grohne <helmut@subdivi.de>]

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