Hi Simon,
Thanks for the response! Comments below.
On 9/26/23 08:33, Simon McVittie wrote:
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
