Hi David, David Kalnischkies <david@kalnischkies.de> (2023-05-04): > before I am playing bug ping-pong (as I don't think we can do much > about this on the apt side), let me ask a d-i question first: Entirely fair, thanks. Putting debian-boot@ in copy since currently the bug is assigned to apt… and others might have some feedback about my proposal(s). > Why is d-i calling 'apt-get clean' to begin with? Checking occurrences of `apt-get clean` (I didn't check for variations) in our packages, I see two callers. One is pkgsel (which deals with tasksel and pulls many/most packages), and one later on in finish-install (which as you can guess runs at the end). > Is it perhaps just wanting to remove /var/cache/apt/archives/*.deb ? > If so, could you switch to: -o APT::Keep-Downloaded-Packages=false > (well, probably in a conf file rather than on each command line). There are various apt-get (not clean) calls, some of them wrapped, and I have no idea what the consequences of tweaking them could be. In any case, while deplying a conf file during the installation process could be attempted, it's far too late to try toying with that… We can probably keep track of the suggestion via some bug report against debian-installer, so that someone can investigate that post-Bookworm (probably removing the possible tweak discussed below). > This instructs apt(-get) to remove the deb file right after it has > installed them with dpkg, which might even be beneficial for space > constraint installation targets. At the very least it is a much used > & tested option as it is the default with apt (but not apt-get). OK, thanks. > d-i could also "just" run 'apt-cache gencaches' to create the caches; > but perhaps it is intended that the caches are gone (docker people e.g. > like to do that I am told, but they nuke other things as well…). The finish-install call can be traced back to: https://bugs.debian.org/586434 > > > - Fix "bash-completion". Make it work even if /var/cache/apt/*.bin are > > > not present (for example, by recreating them on-the-fly) > > The completion script explicitly disables the recreation on-the-fly as > creating the files takes a while robbing users for many seconds of their > interactivity. So, we can't just "fix" the completion script as that has > a(nother?) set of users complain as well. With all the backstory, the interactions/dependencies between bash-completion and apt's internal files became clear, thanks. For Bookworm, I'm tempted to add `apt-cache gencaches` after `apt-get clean` in finish-install, restoring the files bash-completion relies on. That'd waste some little time, rebuilding some of the files that were just deleted… but at least we wouldn't risk anything in the rest of the installation process. (Maybe making the extra call conditional to bash-completion's being installed? Not sure about the “small optimization” vs. “different apt files depending on the installed packages” balance.) Cheers, -- Cyril Brulebois (kibi@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature