Hi Stefano,
Thanks for your quick reply! More thoughts inline below.
On 9/26/23 07:08, Stefano Rivera wrote:
Thanks for taking on a much bigger job than you probably expected to
have signed up for :)
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.
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