Bug#1021289: apt-listbugs: behaviour under unattended-upgrades is suboptimal; do pinning in `apt update` step?

2022-10-06 Thread Francesco Poli
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


Bug#1021289: apt-listbugs: behaviour under unattended-upgrades is suboptimal; do pinning in `apt update` step?

2022-10-04 Thread Paul Wise
Package: apt-listbugs
Version: 0.1.36
Severity: normal

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.

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.

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. At this point apt-listbugs
should not do any prompting or errors, since it is not running in the
interactive mode. Then when `apt upgrade` is run the apt-listbugs hook
will see pinning, not abort the upgrade and the upgrade will complete,
minus the packages that could not be upgraded due to bugs.

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.

-- System Information:
Debian Release: bookworm/sid
 APT prefers testing-debug
 APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), 
(800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 
'experimental'), (690, 'buildd-experimental')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt-listbugs depends on:
ii apt 2.5.3
ii ruby 1:3.0+3.1
ii ruby-debian 0.3.10+b7
ii ruby-gettext 3.3.3-2
ii ruby-soap4r 2.0.5-5
ii ruby-unicode 0.4.4.4-1+b4
ii ruby-xmlparser 0.7.3-4+b3

Versions of packages apt-listbugs recommends:
ii ruby-httpclient 2.8.3+git20211122.4658227-1

Versions of packages apt-listbugs suggests:
ii chromium [www-browser] 106.0.5249.91-1
ii dillo [www-browser] 3.0.5-7+b1
ii elinks [www-browser] 0.13.2-1+b3
ii firefox [www-browser] 105.0.1-1
ii firefox-esr [www-browser] 102.3.0esr-1
ii links [www-browser] 2.27-1+b1
ii lynx [www-browser] 2.9.0dev.10-1+b1
ii netsurf-gtk [www-browser] 3.10-1+b3
ii reportbug 11.5.1
ii sensible-utils 0.0.17
ii w3m [www-browser] 0.5.3+git20220429-1+b1
ii xdg-utils 1.1.3-4.1

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part