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
signature.asc
Description: signature
