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.
