apt-listchanges installs a timer, apt-listchanges.timer, whose sole job
seems to be to attempt to run apt-listchanges.service, a service that
only needs to run once per machine, asynchronously rather than doing it
synchronously from the maintainer scripts.

Using a service for this seems entirely reasonable. However, there are
many different ways to kick off a service asynchronously. For instance,
you could use `systemctl --no-block start`, or for that matter use
`systemd-run` to run a transient unit. Both of those would avoid needing
to have a periodic timer.

I am using a timer for this because if the machine is rebooted while the
job is in the middle of running then it needs to be retried after the
reboot, and that needs to keep happening until it runs to completion.
This is actually a somewhat common scenario since people are told to
reboot immediately after an update if a new kernel version was installed.

As far as I can tell, neither of the other two options you suggested,
`systemctl --no-block start` or `systemd-run`, will achieve the stated goal.

The timer approach I'm using seems like the most straightforward and
reliable.

If you have another suggestion that will achieve it without using a
timer, I'm all ears.

jik

In an ideal world, I would suggest:
- running it asynchronously from the maintainer script,
- print a message from the maintainer script saying how to run the job
  manually if it gets interrupted, "or it will be run synchronously on
  the next apt upgrade", and
- when apt-listchanges runs at upgrade time, if it hasn't yet been run,
  run it synchronously then.

The solution you propose would provide a dramatically inferior user experience to the current implementation. I'm not going to do that.

While my timer solution is unconventional, it is deterministic and straightforward, works as intended, and provides a good UX. I'm not going to change it to something with an inferior UX over vague discomfort with the idea of using a timer this way.
-- 
Sent from my phone. Please excuse brevity and autocorrect errors.

The concrete concern here (which I should have been much clearer about,
sorry) is that it delays the job to the next hour, rather than starting
it immediately. The behavior changes I'm looking for are to start doing
the work right away, and to make sure the work happens *before* the next
apt run, even if that takes time.

Consider this scenario, which is not an unreasonable one for folks to
try when doing a large upgrade:

1) Upgrade apt/dpkg and related packages first.
2) Upgrade the rest of the world immediately afterwards.

It's not unreasonable for someone to include apt-listchanges in group
(1).

Thanks for the additional info, it is helpful.

I think I need to clarify here that the database population is an
optimization.

If a particular package hasn't been populated into the database when
apt-listchanges is asked to display changelogs or news for it, then it
will automatically populate that package synchronously. This is as
opposed to your suggestion to run the entire database population job
synchronously at upgrade time, which would take much longer than
necessary because it would populate all packages, not just the ones
being upgraded.

It may be reasonable to do a `systemctl --no-block start
apt-listchanges.service` at the end of the upgrade rather than waiting
until it's kicked off by the timer. I will need to think about the
potential repercussions of that.

jik

I did not realize that apt-listchanges was fully capable of doing
without the database. If that's the case, then this is a much more minor
concern. I do still think it makes sense to kick off the job
asynchronously right away, but I agree that if apt-listchanges will
behave entirely correctly in the absence of the database, then there's
no value in running the *entire* job synchronously at any point.

Thank you for the further explanations!