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

[David Kalnischkies]

Am Sat, Dec 28, 2024 at 12:01:57PM +0100, schrieb Johannes Schauer Marin Rodrigues:
> > Random example from my host:
> > | $ apt-config dump --no-empty | grep -i '::\(pre\|post\)-'
> > | APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/swcatalog -a -e /usr/bin/appstreamcli; then appstreamcli refresh --source=os > /dev/null || true; fi";
> > | DPkg::Pre-Install-Pkgs:: "/usr/bin/apt-listchanges --apt || test $? -lt 10";
> > | DPkg::Pre-Install-Pkgs:: "/usr/sbin/dpkg-preconfigure --apt || true";
> > | DPkg::post-invoke:: "[ -x /usr/lib/libdvd-pkg/b-i_libdvdcss.sh ] && /usr/lib/libdvd-pkg/b-i_libdvdcss.sh || true";
> > 
> > So, in a sense, I think you are just "lucky" that you ran into this
> > problem class with dpkg-preconfigure/apt-extracttemplates as depending
> > on what you install in your chrootless chroots other fun stuff might happen.
> 
> Yes, chrootless installations should only be done in another chroot layer
> anyways, which limits the damage. Our CI system is running mmdebstrap in
> chrootless mode inside a normal mmdebstrap. This is not only necessary to
> prevent damage to the host system but also because the system on the outside
> should have the same packages and versions installed as the chrootless system
> because we have no way to express maintainer script dependencies by themselves
> (yet).

My point was that packages you install in your chrootless chroot can
contain apt snippets that effect later apt calls including registering
various hooks (the same could happen to dpkg if it supports picking up
config from a different place some day). debconf just happens to be
installed by default and hence brings in the hook by default and debconf
happens also to be installed on the host. That might change with the
other examples if you install them in your chroot.


Other examples of packages modifying also other apt settings might be
apt-file or appstream and its icon-packages that lead to additional
downloads. Is the idea here to play wack-a-mole as specific problems
arise or figure out a "generic" approach?

IF chrootless goal is just to support a very tiny controlled subset
the solution might be different to e.g. reaching prio:standard and
upward (apt-listchanges is prio:standard).


> > Another more specific option might be to "just" react in
> > dpkg-preconfigure to DEBIAN_FRONTEND=noninteractive and exit as
> > I suppose the point of preconfiguring is to front load interactivity,
> > but if there will be none no extractions have to happen.
> 
> This is only tangential to this bug. I think what should be done is what Helmut
> suggests and that is that mmdebstrap unconditionally disables
> DPkg::Pre-Install-Pkgs for all installations because it sets
> DEBIAN_FRONTEND=noninteractive unconditionally as well so there is no point in
> running dpkg-preconfigure, right?
> 
> Whether or not dpkg-reconfigure should be doing something about the presence of
> DEBIAN_FRONTEND=noninteractive can be handled individually from that.

Sure you can treat it as tangential, but before you make mmdebstrap
a special snowflake in this regard I would see if we could solve that
issue more centrally for everyone: mmdebstrap isn't the only thing in
existence that runs 'noninteractive' to avoid debconf questions. Very
many things do and even if the hook script doesn't fail for them, it at
least wastes time for them all now that you can't avoid it by just not
installing apt-utils early on. '#clear' works for you now because it is
the only hook in your package selection. If that selection is larger
there are more hooks and some might not be as ignorable.

So, in my view this isn't tangential, but my most preferred solution:
make "dpkg-preconfigure --apt" a conditional noop (if possible) as
that requires no changes elsewhere and solves a problem many might not
have realised yet they have – and all thanks to some strange folks with
fringe use cases nobody cares about. Hurray for fringe use cases! 😉

In a way, "solving" this problem class "also" with '#clear' just for
mmdebstrap is the tangential to this bug for me…


Best regards

David Kalnischkies

P.S.: mmdebstrap is not even the only thing doing a chrootless operation…
apt does it itself in its tests, even before dpkg supported it by
preloading a library that noops chroot() and rewrites execvp() calls.
We don't use 'normal' deb packages through but craft our own to test
e.g. behaviour around failing maintainer scripts. That was the reason
for e.g. talking to myself for years in #824774.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debconf-devel/attachments/20241228/286f67a2/attachment.sig>