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
On 10/2/24 12:33 PM, Josh Triplett wrote:
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).
On Thu, 26 Sep 2024 22:23:05 -0400 Jonathan Kamens<j...@kamens.us> wrote:
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.
On September 26, 2024 4:35:07 PM EDT, Josh Triplett<j...@joshtriplett.org>
wrote:
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.
