Hi Stefano,
Thanks for your quick reply! More thoughts inline below.
Indeed, this has turned out to be a larger endeavor than I had expected, but on the flip side, it's got just the right combination of Debian packaging stuff and programming challenges to make it the perfect first Debian package for an experienced programmer to maintain. I'll come out of this with a lot of useful new experience and hopefully apt-listchanges will come out of it better as well.Thanks for taking on a much bigger job than you probably expected to have signed up for :)
I wasn't aware of this particular bit of unusual packaging. changelog.Debian.*.gz doesn't look like something that is described in Debian Policy. From what I can see, I presume this is a legacy changelog from when devmapper was imported into lvm2. I wouldn't expect it to ever get new entries. So, continuing to ignore it would probably be reasonable. Is this a pattern that we see in other binary packages, where new entries do appear?
I did an apt-file search for "changelog.Debian" and filtered out the standard names from the resulting list. The result is about 50 files which, I agree, mostly look like either copies of changelogs from other packages (e.g., all of the cross-compiler binutils packages have a changelog.Debian.binutils.gz which I assume is a copy of the one in binutils) or old changelogs which are no longer changing. So looking at what's in the repository, you're probably correct that there would be little harm in ignoring non-standard files right now.
Given that the Debian Policy mandates the use of changelog.Debian[.gz] or changelog[.gz] for native packages, perhaps you're right that I should continue to ignore other files with non-standard names. The rest of the proposal, i.e., using checksums instead of version numbers to determine which entries to display, would remain.
BTW, this issue does remind me of a bug I think I've seen in apt-listchanges where it isn't ignoring changelog entries copied over from a previous versioned source package (something like gcc-* or python3.*). I can't reproduce it right now to file it, though :( Does that sound familiar?
Given that e.g. each gcc release has a different source package name (gcc-12, gcc-13, etc.) the current apt-listchanges logic could absolutely redisplay a changelog entry for one gcc major release that you already saw for a different major release. On the other hand, that's arguably the correct behavior when the same change is made separately to both of those packages. This is why my proposal limits the content checksums to only being applicable within a single source package.
jik