Control: reassign -1 apt-listchanges 2.85.13 Hi, On Mon, Oct 02, 2023 at 05:43:00PM -0400, Jonathan Kamens wrote: > The timing of when apt-listchanges gets called vs. when packages get > installed is controlled by apt, not by apt-listchanges. While it would apt doesn't hardcode calling apt-listchanges. apt-listchanges opts in to being called at a specific point with `/etc/apt/apt.conf.d/20listchanges`. Specifically the `DPkg::Pre-Install-Pkgs` setting. Other hook places exist, they do have other informations available through. In any case, as the premise for reassigning is wrong… return to sender. > certainly be possible to add an option to apt to call apt-listchanges after > rather than before the upgrade, and to omit the --confirm option when doing > so since it obviously makes no sense to ask the user for confirmation afrer > the upgrade has already happened, this change would need to be made in apt, > not in apt-listchanges. You could already now gather the info with a non-blocking hook and add an additional one after dpkg finishes which does whatever is requested here via `DPkg::Post-Invoke` hook if you so choose. That said, my `/etc/apt/listchanges.conf` contains: |[apt] |frontend=browser |browser=/etc/apt/apt-listchanges-browser |confirm=0 |which=both I have to admit that my browser is kinda special so I will not bore you with too many details, what you need here is going from 'root' to a 'normal' user (with some environment variables like DISPLAY). I think apt-listchanges even tries to do that for you if you use `sudo` to call apt (or whatever front end ends up calling listchanges), so it might just work for you or you need a bit of scripting (my solution involves a systemd user session, a user account just for browsing and sandboxing, but as this is total overkill and not a generic solution). In any case, the behaviour is that apt-listchanges will format its output as HTML, calls the browser on it (ensure that either a browser is running or double fork to the background I suppose) after which it will continue without a confirmation as requested in the bugreport. I use that for years to read the changelog entries (not just NEWS) and occasionally the linked bugs while apt/dpkg are busy doing their thing. So, I suppose, with a bit more documentation and testing this bugreport could be closed in apt-listchanges without any code changes. In any case, there is nothing I can see we as apt maintainers need to do here. If you think you (I see that you intend to adopt apt-listchanges, good luck with that & thanks for contributing to Debian in this way!) need something from apt feel free to contact us on IRC/mailinglist before reassigning bugs over as they tend to get lost in our heap – and usually, with some trickery existing facilities can be reused instead of busy-waiting for apt in stable to support whatever someone needs now… Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature