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

Sat Dec 28 11:01:57 GMT 2024

Hi David,

Quoting David Kalnischkies (2024-12-27 18:48:20)
> Am Thu, Dec 26, 2024 at 12:41:42PM +0100, schrieb Johannes Schauer Marin Rodrigues:
> > Should apt gain support for being told that it's doing a chrootless
> > installation and then pass the right options or environment variables to the
> > DPkg::Pre-Install-Pkgs scripts it calls?
> 
> I think it should… after all, you kinda already do tell apt to go look
> elsewhere with an assortment of options for sources.list, config,
> dpkg.status, lists/, archives/, … so adding yet another option can't
> hurt that much, can it?

depends on what makes you hurt I guess. I think it mostly is a matter of how we
design the interface. We may get away without adding another config option to
apt. If mmdebstrap is the only user of such an option I also don't think it
makes much sense in practice, no?

> That said, semantics might be tricky…
> 
> I am assuming you use the "chroot" apt config, but the various hooks
> tend to use absolute paths ~ in other words paths on the host.
> Many of those hook interfaces are invoked via $SHELL and I am certainly
> not looking forward to implementing a $SHELL parser so we could mangle
> the absolute paths into the "chroot" ……… sometimes?

Yes, that would not be a good way forward.

> 
> 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).

> (And that "ignoring" the preconfigure has no consequences for you as the
> config intermixed with the installation is silenced anyhow)

Did you read Helmut's reply to this bug? I'd like to hear your thoughts about
his idea. If we do not need dpkg-preconfigure anyways, because we do not ask
any debconf questions in the first place, then this whole problem becomes
completely moot.

> How is this "solved" for maintainer scripts? I mean the ones which don't use
> just sed and grep which you can easily provide and use from the host but lets
> say texlive or the libdvdcss from above?

Maintainer scripts have to be manually touched to add support for DPKG_ROOT.
Right now, only Essential:yes, build-essential and init support it. So you can,
for example create a bootable Hurd installation on Linux even though you cannot
run any Hurd binaries on Linux (even QEMU would be of no help here) but to
install packages beyond what is needed to boot a shell you would do that on the
real system. It's also not very interesting to add support for DPKG_ROOT to
many more packages because this is mostly interesting for bootstrapping
purposes.

> The most immediate option here might just be to have a
> | $ cat /path/to/chroot/etc/apt/apt.conf.d/99z-disable-hooks.conf
> | #clear APT::Update::Auth-Failure;
> | #clear APT::Update::Pre-Invoke;
> | #clear APT::Update::Post-Invoke;
> | #clear APT::Update::Post-Invoke-Stats;
> | #clear APT::Update::Post-Invoke-Success;
> | #clear APT::Install::Pre-Invoke;
> | #clear APT::Install::Post-Invoke-Success;
> | #clear DPkg::Pre-Install-Pkgs;
> | #clear DPkg::Pre-Invoke;
> | #clear DPkg::Post-Invoke;
> 
> Those are at least the ones I found with `git grep RunScripts`,
> I kinda suspect more to exist… who knows, right? 😉

Thank you, I had forgotten about the #clear directive.

Unless apt changes the way it calls these scripts, for example by adding an
environment variable, I think I should just disable all of these in chrootless
mode.

> 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.

> (obligatory mention of it being sad that this functionality is in apt to
>  begin with as this is not something apt should be doing. It doesn't
>  usually poke into deb files…)

(obligatory mention that dpkg-reconfigure is called dpkg-* even though it is
not in dpkg :D)

> A very fine time sink you stumbled over.
> Package management is clearly a hard problem, not just for Santa.

I blame Helmut for having had the idea of chrootless package installations and
now I have a new hobby. :)

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/debconf-devel/attachments/20241228/f3863bd8/attachment-0001.sig>