Control: tags -1 + moreinfo
On Wed, 05 Oct 2022 09:18:55 +0800 Paul Wise wrote: > Package: apt-listbugs > Version: 0.1.36 > Severity: normal Hi Paul, thanks for your bug report. > > The behaviour of apt-listbugs under unattended-upgrades is suboptimal: > > * It causes the apt run to abort before it can start. > - With minimal steps mode some packages may be upgraded, but once a > bug is found, no subsequent package upgrade steps can be run. > * The messages say that pinning is being added but they are not added. This sounds awkward to me, since there's code in apt-listbugs to detect non-interactive sessions and modify the behavior accordingly. Specifically, when apt-listbugs sees that its stdout is not a terminal, it automatically assume the following options: --quiet --force-pin --force-no This automatic behavior change should ensure that all buggy packages (of the upgrade/installation that is about to happen) are pinned, without any interactive prompt. I assume unattended-upgrades runs the package manager without connecting stdout to a terminal... More investigation is needed in order to figure out why you didn't see the pinning added. I assume unattended-upgrades runs the package manager with root privileges... > > Since unattended-upgrades are not interactive the user can never > interact with apt-listbugs to add pinning and cannot restart the apt > session, which is currently required for the pinning to take effect. Did you configure unattended-upgrades to attempt the upgrade twice in a row (as suggested in the FAQ[^note])? [^note]: see /usr/share/doc/apt-listbugs/FAQ.md.gz I admit that I am not familiar with unattended-upgrades, hence I am not sure how to configure it for the twice-in-a-row upgrade. I hope it's easy enough. > > For this reason I suggest that when in non-interactive mode, a hook for > APT::Update::Post-Invoke (run by `apt update`) is added that will > invoke apt-listbugs and add pinning for any packages that need pinning > added and removing any that no longer apply. I think this cannot work, unfortunately. In order to know which packages are going to be upgraded (or newly installed!), apt-listbugs must receive information from the upgrade (or install) session of the package manager. The update of the repository indexes is not enough, since the package manager does not yet know what the user will request (just install one or two packages? upgrade all the package that can be upgraded? upgrade only some packages? nothing at all for the time being, since the upgrade/install will happen later?). And apt-listbugs would anyway be unable to distinguish between non-interactive repository index updates and non-interactive updates immediately followed by non-interactive upgrades. I mean: some users desire unattended repository index updates, but want to do the package upgrade interactively. If apt-listbugs is invoked during an "update" and sees that stdout is not a terminal, how can it tell whether this is an unattended "update" or an unattended "update + upgrade"? [...] > Please set the Explanation field to say that the package pin was added > automatically, so that sysadmins reading it understand that the pin was > added by apt-listbugs rather than being set by a sysadmin. This could perhaps be done, but I am not sure I see its usefulness. A sysadmin who uses some unattended package upgrade mechanism will see a good number of automatically added pins. Possibly (almost) never a pin added during an interactive session. On the other hand, a sysadmin who does not use any unattended package upgrade mechanism, will only see interactively added pins. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgp136t3XhTFX.pgp
Description: PGP signature
