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! On Wed, 2 Oct 2024 12:59:51 -0400 Jonathan Kamens <j...@kamens.us> wrote: > 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.
