OK, this will be fixed in 4.1. Description of the bug and fix, copied
from the commit message:
Bug:
* Main package a has both changelog and NEWS.
* Subpackage a-sub has identical changelog but no NEWS.
* Both a and a-sub version 1 are installed but not in database.
* apt goes to upgrade a and a-sub to version 2.
* apt-listchanges parses a-sub first, records installed entries under
package a instead of a-sub, since we were using the package name in
the changelog entry to determine where in the seen DB to record
entries.
* apt-listchanges parses a, sees that there are entries for it in
database, therefore does not parse installed entries so does not
notice NEWS entry in installed package.
* As a result, apt-listchanges displays NEWS entry for a when it
shouldn't have.
Fix:
* Associate entries with binary package names, not the package name in
the changelog entry itself.
* When checking if an entry has already been seen, check across all
packages, not just the binary package being parsed. To facilitate
this, the seen database maintains a merged dict of all checksums.
I added a unit test for this case which now passes, and all other unit
tests continue to pass with the change described above.
Additional FYI comments below.
On 10/9/23 14:05, Axel Beckert wrote:
Anything I can help? This is a Sid installation running more or less
permanently (besides reboots :-) since May 2016. So the
apt-listchanges database might have seen a few packages. Then again,
it seems rather short for > 14'000 installed packages.
Note that the database is entirely replaced when upgraded from pre-4.0
to 4.x because its format and what we're storing in it are completely
different.
BTW, while trying to figure out where that db could be I noticed that
despite 4.0 is installed according to "dpkg -l apt-listchanges", the
tool itself contains a different version number:
~ → head -2 /usr/bin/apt-listchanges
#!/usr/bin/python3
# EASY-INSTALL-ENTRY-SCRIPT:
'apt-listchanges==3.27','console_scripts','apt-listchanges'
Thanks, fixed this as well.
jik
