Hi Simon,
Thanks for the response! Comments below.
If we disregard non-standardized files like changelog.Debian.devmapper.gz, I think we can model changelog entries as being keyed by (source package, source version) pairs.
Changing apt-listchanges so that it always uses the version number of the source package instead of the current logic which uses the "maximum" version number of all the binary packages in the group would solve the lvm2 / dmsetup problem but wouldn't solve a different problem: binary packages with different changelogs for the same source package version, installed at different times.
Example:
Source package foo produces binary packages foo-bar and foo-baz. The maintainer has opted to use separate changelog files for foo-bar and foo-baz which enumerate just the changes in those specific packages. The maintainer submits foo-bar-1.1-2 and foo-baz-1.1-2. It's discovered shortly after they're released that there's a packaging error in foo-baz-1.1-2, so it's pulled while the error is being fixed. In the meantime, the user upgrades foo-bar to 1.1-2, and apt-listchanges displays the changelog entries from its changelog. When foo-baz-1.1-3 is released and the user upgrades to it, apt-listchanges won't show them its changelog entries stamped 1.1-2, because the current implementation thinks they've already been seen.
Yes, it's an edge case, but it will definitely happen occasionally.
It also won't solve the problem that version comparisons are brittle and become confusing and ambiguous when, e.g., a package is updated in both stable and unstable and there are different version numbers in the changelog entries on the two branches.
My proposal will, I believe, solve both of these problems better.
My proposal also leaves open the possibility of being able to
display arbitrary changelogs in the future, even those not
specifically in compliance with the Debian Policy.
To be clear, I agree that switching from "use the maximum package
number of all binary packages associated with this source" will be
qualitatively better than what apt-listchanges does now, and
certainly it would be far easier to implement than what I'm
proposing. I'm just not sure it goes far enough.
(One exception to that: binNMUs generate a special binNMU changelog entry, which doesn't correspond to a source package as-is, but apt-listchanges would presumably want to behave as though that source package had existed for the purposes of changelog entry display.)
Yeah, apt-listchanges already handles binNMUs differently. Honestly I don't quite understand what's going on there and I need to dig in and understand it better, but whatever logic is currently in place to handle them differently will be preserved regardless of what I end up changing.
jik