Johannes Schauer Marin Rodrigues <jo...@debian.org> writes:
> * 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
In general, Policy doesn't need to be a copy of dpkg's documentation, so I
don't think we need to list everything that dpkg makes available.
The important thing that Policy is adding isn't to catalog the facilities
available. It's to tell you *when* to use those facilities. In the case
of some of those variables, that's the obvious "whenever it's convenient
to get that information from an environment variable for whatever you're
trying to do," and Policy doesn't need to say anything about it. But
here, some packages *have* to use this environment variable or they will
be buggy. That's the sort of thing Policy should describe.
I would tend to add a section on bootstrapping support (since that's what
this is for) to chapter 6 at the end. It could just talk about DPKG_ROOT
for now and we can add any other maintainer script considerations that
come up there in the future.
> * 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).
I think this is up to you to define, but we need to be able to describe
it. Starting with essential and build-essential packages sounds great,
and Policy already defines both of those terms, so that's easy. If you
need to add more packages, we will need to figure out how to describe them
without special-case listings of package names.
> * 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?
It sounds like you're not imposing any restrictions on the *package* here,
so there's no need to say anything unless at some point you need to do so.
The point of putting this in Policy is to provide guidance to the
packagers, not to the bootstrappers. Presumably you already have other
documentation that you maintain about how to bootstrap Debian that spells
out what to do in what order; that's outside of Policy's remit. What
Policy is trying to do is to define for packagers what interface they have
to implement, and DPKG_ROOT is now part of that interface.
So in other words, you can just say something like:
Maintainer scripts in essential or build-essential packages must
preface all paths they act on in maintainer scripts with an expansion
of the DPKG_ROOT environment variable. This will normally be empty
(and thus normally will not change anything), but in some situations
it may be set to a bootstrapping path to tell packages to act under
that path instead of on the root file system.
That wording probably isn't quite right, but I think that's the general
idea.
> * 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.
If maintainers don't have to worry about this for upgrades, you can just
say so. I think it's up to you whether you think that is important or
not. I would be inclined to say that it's *safe* to add DPKG_ROOT to
paths even on upgrade actions, but you only *must* do so for maintainer
script actions that run during initial installation.
Thank you very much for starting this discussion!
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
