Comment 7 for bug 2049208

> We should absolutely NOT be overriding the debconf frontend on a per-package basis

Not exactly what I was talking about. needrestart has two UIs by default, debconf and stdout. The former is considered interactive, not the latter.

>>> If needrestart detects systemd it will assume that libpam-systemd is used and relies on cgroup names to detect if a process belongs to a user session or a daemon

>> I'm assuming we're only considering scenarios where libpam-systemd is used?

> Those are the situations today where the behavior is definitively buggy. In particular, I have witnessed needrestart asking me REPEATEDLY, on SUCCESSIVE apt commands in a container, whether or not to restart the same set of services that I declined to restart after the initial apt upgrade.

To clarify, are you complaining about the heuristics, or about the fact that it doesn't remember your choices? Because if we generate a "temporary override" to avoid the latter, it brings in another set of questions: how long do we keep it? Until the user session closes? Until next reboot? For X hours?

> But the right solution is that I should never have been prompted at all which services to restart: I'm in an apt transaction, services are supposed to be restarted as needed, and the helper tool should not bother me but default to ask which services I want to restart or not.

> This says nothing about whether "restart required" notifications should use the same debconf priority (or, whether they should be debconf prompts at all).

Agreed, it would make sense to split the reboot prompts from the service restart issues.

>> needrestart defaults to not doing anything
>> when using a non-interactive backend)

> Then that is also a bug which must be fixed. The debconf frontend is always non interactive when running under unattended-upgrades; failing to restart affected services when auto applying security updates is critically BROKEN BY DESIGN

Sorry, that's my fault, I expressed myself poorly. needrestart considers debconf as interactive regardless of the debconf frontend.