Comment 1 for bug 1936175

How about fully decoupling the hook and the check?

Like letting /usr/lib/update-notifier/update-motd-updates-available only do the post-apt processing if a check "is needed" and then touch a stamp or similar.
That would give apt the fast path we want to have.

Independently we could then have something that regularly checks if the stamp exists or changed - and if so run the actual "/usr/lib/update-notifier/apt-check --human-readable" to output to "/var/lib/update-notifier/updates-available" which is what motd will later consume.

I think nowadays we can do better than "check every x minutes" like thtough systemd https://www.freedesktop.org/software/systemd/man/systemd.path.html.

Imagine (untested suggestion) instead of writing to:
  /usr/lib/update-notifier/update-motd-updates-available
it would only write the output of `date` to:
  /usr/lib/update-notifier/update-motd-updates-available-needcheck

Then we could have:
$ cat /etc/systemd/system/update-motd-updates-available.service
[Unit]
Description=Update list of available updates for update-notifier
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/lib/update-notifier/apt-check --human-readable
StandardOutput=file:/usr/lib/update-notifier/update-motd-updates-available

$ cat /etc/systemd/system/update-motd-updates-available.path
[Path]
PathModified=/usr/lib/update-notifier/update-motd-updates-available-needcheck

[Install]
WantedBy=multi-user.target

I'd hope that this would achieve
a) apt transactions being fast
b) the info of available packages will be updated immediately
c) the old issues of 1527710 were around mount/chroot/umount and similar.
   In those the service would not run -> no conflict
d) since there is no direct child process other old issues e.g. preseeding
   should also not be affected anymore

Opinions?