Dear Maintainer,

downgrade / wishlist as you see fit.

Since the default options only allow you to quit and carry on, it makes no
sense to stall the installation of packages with the default settings.

Please provide an option to display changes after the installation of the
package(s) has finished.

And optionally, make it default.

I like to see changes, i hate hitting upgrade walking away and coming back to
find it stopped after download because "epson drivers were removed from
printer-guten" etc.

:)

Thanks!

The timing of when apt-listchanges gets called vs. when packages get
installed is controlled by apt, not by apt-listchanges. While it would
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.

Hi,

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.
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