Hi, (I saw this e-mail by chance and want share my two cents -- I am not an authoritative voice for apt-listchanges in any way)
As with other issues related with automatic management of a system in general, I don't think that there's a workable way to satisfy this request. Things start to break apart when one starts to look closely into the implementation details. For example... 2016-05-13 10:04 Raphaël Hertzog:
Package: apt-listchanges Version: 2.89 Severity: wishlist It happened multiple times that I have been annoyed by a NEWS.Debian saying that some perl library installed on my system got some backwards incompatible change. I have that perl library as a dependency of something else and I don't care about this change. I assume the package I care about has been fixed to work with that version since the dependencies allow the update. Thus I would like apt-listchanges to not display this message. I'm not sure what is the best approach but there are multiple ways to deal with this: - by showing messages only from packages which are marked as manually installed (apt-mark showmanual) but this might be a bit too restrictive this should be extended to include (first-level) dependencies of manually installed metapackages as well (Section: metapackages)
I think that this is not practical, because one might have gcc or gcc-6 installed as a convenience package (or same with linux-* "convenience" packages) and are genuinely interested in the detailed changes of the compiler, but then apt-listchanges will not show the details of those packages, only of the higher-level "convenience" packages.
- by hiding messages of library packages (Section: libs, perl, ruby, python, etc) which have been automatically installed (apt-mark showauto).
I am very much interested in the changes of openssl or libc, even if I don't pay attention in general to the news items of libs or the other sections that you mention.
Whatever you decide in the end, I believe this feature should be enabled by default.
One only needs to miss an important NEWS item that actually matters for that particular system/case (e.g. change in an interpreter that subtly breaks your code) to realise that one has been filtering away one step too much. And one only realises of those things too late, when things break that one cares about. But this specific thing that one cares about and breaks is different for every person. Still, perhaps it's possible to provide filters based on the examples above, so people can use them if they wish. But I don't think that it should enabled by default in any way, because that would break expectations of people that have been using apt-listchanges for more than a decade. apt-listchanges already asks about config details through debconf, so perhaps adding another question related to this would be easy -- if and once the filters are implemented, of course. Cheers. -- Manuel A. Fernandez Montecelo <[email protected]>
