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? 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? 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. (And that "ignoring" the preconfigure has no consequences for you as the config intermixed with the installation is silenced anyhow) 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? 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? 😉 It /might/ makes sense to deprecate all the various hooks and do something slightly more controlled aka declarative at least on the "what on earth are we supposed to run" part of the interface. I suppose Julian is screaming JSON hook or varlink at me now, but that might be yet another beast to deal with. 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. (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…) A very fine time sink you stumbled over. Package management is clearly a hard problem, not just for Santa. Best regards David Kalnischkies
signature.asc
Description: PGP signature
