[Debconf-devel] Bug#1091442: dpkg-preconfigure calling apt-extracttemplates breaks DPKG_ROOT support

Helmut Grohne helmut at subdivi.de
Thu Dec 26 19:27:29 GMT 2024


Hi,

On Thu, Dec 26, 2024 at 01:51:15PM +0000, Colin Watson wrote:
> On Thu, Dec 26, 2024 at 12:41:42PM +0100, Johannes Schauer Marin Rodrigues wrote:
> > since the upload of debconf 1.5.88 a few days ago, building chrootless Debian
> > chroot tarballs is broken if not using fakeroot. Specifically, since that
> > upload, /var/cache/debconf/ and /var/cache/debconf/tmp.ci/ outside the chroot
> > will get modified or created, respectively. I tried to come up with a patch but
> > am left with more questions than answers and am thus reaching out to the
> > debconf maintainers as well as the readers of the deity list. There is a bit to
> > unpack, lets start with a patch that works around the issue in our CI [1]:
> 
> Eww.  What a mess.

Thanks for noticing!

> > But dpkg-preconfigure is called by /etc/apt/apt.conf.d/70debconf via
> > DPkg::Pre-Install-Pkgs and thus does *not* have the DPKG_ROOT variable set as
> > it is not executed by dpkg but by apt itself. We are thus not able to figure
> > out that this is supposed to be a chroot installation.

This is a corner of Debian I'm not experienced in, so I am only catching
up now and writing down my limited understanding.

Contrary to its name, dpkg-preconfigure is not part of dpkg, but
debconf. It is run by apt via DPkg::Pre-Install-Pkgs before any package
unpacking and extracts and runs the *.config scripts contained in
control.tar. The benefit here being that the installation does not
scatter debconf prompts to various maintainer scripts and asking (most
of) them ahead of installation in one batch.

(Please now point out how wrong I am.)

Now mmdebstrap goes to great lengths to avoid debconf questions by
setting DEBIAN_FRONTEND=noninteractive and
DEBCONF_NONINTERACTIVE_SEEN=true. It really does not want to answer
those questions interactively. If you really want to answer them, man
mmdebstrap suggests running debconf-set-selections from an
--essential-hook. So really, what is the benefit of running any of these
when run from mmdebstrap? We want the answers to be deterministic in the
interest of reproducibility. Unless I am mistaken, we also want the
.config scripts to not have any effect when being non-interactive as you
cannot rely on them being run (e.g. when installing a package with dpkg
directly).

> > I'm am looking for ideas of how to fix this.

I question why we run dpkg-preconfigure from mmdebstrap. In what
situation can it have any beneficial effect?

(Not running it also speeds stuff up.)

> dpkg-preconfigure arguably shouldn't need to bail out; since debconf
> supports DPKG_ROOT, it would be sufficient if DPKG_ROOT were set when
> dpkg-preconfigure is called, since that would mean it would use a
> debconf database in the right place.  (Well, nearly.  dpkg-preconfigure
> currently hardcodes /var/cache/debconf/tmp.ci, but that's easily fixed.)
> In general it seems better to me if chrootless installations take more
> similar code paths to normal ones.

debconf was required to support DPKG_ROOT, because it is run from
maintainer scripts. I see way less reason to require dpkg-preconfigure
to support this. The DPKG_ROOT variable is meant to be exported by dpkg
for maintainer scripts, but dpkg-preconfigure is not run from a
maintainer script, so the attached semantics do not apply. If we want it
to support on a directory, I argue that it should gain a --root option
instead. I'm not convinced that we should change it at all given the
above though. 

> How viable/evil would it be for something outside dpkg to set DPKG_ROOT?

I think it would be evil. Presently, we kinda imply that if DPKG_ROOT is
set, we're inside a maintainer script and that property gets violated
here. That's certainly debatable, but it also is a significant departure
from the present design.

> Perhaps the caller of apt could just set DPKG_ROOT, since it knows the
> intended installation path and that the installation is going to be
> chrootless?  Then hopefully all we need is something like:
> 
> diff --git a/dpkg-preconfigure b/dpkg-preconfigure
> index 6239603a..a5f9d37d 100755
> --- a/dpkg-preconfigure
> +++ b/dpkg-preconfigure
> @@ -156,7 +156,8 @@ if (! $have_tty && $frontend->need_tty) {
>  	exit 0;
>  }
>  
> -my $tempdir='/var/cache/debconf/tmp.ci';
> +my $root=$ENV{DPKG_ROOT} // '';
> +my $tempdir="$root/var/cache/debconf/tmp.ci";
>  remove_tree($tempdir, { safe => 1, keep_root => 1 });
>  make_path($tempdir);

Given the above I'd rank things like this:

1. Do not call dpkg-preconfigure from mmdebstrap.
2. Add a --root option to dpkg-preconfigure.
3. Your patch.

This is assuming that my limited understanding is lacking errors. Now
please tell me where I'm wrong.

Helmut



More information about the Debconf-devel mailing list