Greetings,
Please note that I am not on the debian-qt-kde list, so please make sure
to include me explicitly on replies.
I've recently adopted apt-listchanges, and I'm trying to figure out what
to do about bug 962078
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962078>.
Specifically, the submitter complains that every time there are a bunch
of KDE package updates, he sees the same changelog messages over and
over in apt-listchanges.
Two examples: libkf5crash5 and libkf5dbusaddons5. Here are recent
changelog.Debian.gz entry from each of them, compared:
--- libkf5crash5.changelog 2023-10-10 10:46:35.862668849 -0400
+++ libkf5dbusaddons5.changelog 2023-10-10 10:47:00.258828016 -0400
@@ -1,48 +1,49 @@
-kcrash (5.107.0-1) unstable; urgency=medium
+kdbusaddons (5.107.0-1) unstable; urgency=medium
[ Aurélien COUDERC ]
* New upstream release (5.105.0).
* Update build-deps and deps with the info from cmake.
+ * Update symbols from build for 5.105.0.
* New upstream release (5.107.0).
* Update build-deps and deps with the info from cmake.
* Release to unstable.
- -- Aurélien COUDERC<couc...@debian.org> Sun, 18 Jun 2023 16:08:34 +0200
+ -- Aurélien COUDERC<couc...@debian.org> Sun, 18 Jun 2023 16:08:27 +0200
-kcrash (5.104.0-1) experimental; urgency=medium
+kdbusaddons (5.104.0-1) experimental; urgency=medium
[ Aurélien COUDERC ]
* New upstream release (5.104.0).
* Update build-deps and deps with the info from cmake.
- -- Aurélien COUDERC<couc...@debian.org> Wed, 15 Mar 2023 16:09:54 +0100
+ -- Aurélien COUDERC<couc...@debian.org> Wed, 15 Mar 2023 16:09:48 +0100
-kcrash (5.103.0-1) unstable; urgency=medium
+kdbusaddons (5.103.0-1) unstable; urgency=medium
[ Aurélien COUDERC ]
* New upstream release (5.103.0).
* Update build-deps and deps with the info from cmake.
- -- Aurélien COUDERC<couc...@debian.org> Sun, 12 Feb 2023 21:44:26 +0100
+ -- Aurélien COUDERC<couc...@debian.org> Sun, 12 Feb 2023 21:44:22 +0100
Ignoring the first one, where the content is (slightly) different and
therefore apt-listchanges can't really be expected to do anything other
than displaying both changelog entries, you can see that the second and
third entries here—and many other changelog entries for these packages,
as well as other KDE packages—are identical except for a different
package name and a slightly different timestamp.
My revamped version of apt-listchanges that is currently in experimental
uses two strategies to avoid displaying the same content to users more
than once:
* Entries that are exactly the same—including the package/version
header and the email/date trailer—are only displayed once regardless
of how many different packages they appear in.
* Entries that come from the same source package and are identical
aside from the package/version header (i.e., the content and the
email/date trailer are identical) are only displayed once.
These KDE changelog entries /just/ different enough to evade both of
these deduplication strategies: their headers have different package
names, they're from different source package, and they have slightly
different timestamps in their footers.
I could theoretically loosen up the sameness comparison to allow these
differences, but honestly, I feel like I'm starting down a slippery
slope here which is going to end with apt-listchanges deciding not to
display something to the user that in fact should have been displayed.
I'm therefore emailing y'all to make you aware of this issue and ask if
there's any room for changing how these packages are built to align the
changelog entries better so that it is safer for apt-listchanges to
dedup them.
For example, if the timestamps on all of these entries could be made the
same, then I could dedup them successfully by allowing deduplication
within the same maintainer as well as within the same source package,
which would be a little weird but seems like it would be sufficiently
cautious to be acceptable. I would really prefer not to have to parse
the date and decide, "Welp, these two dates are close enough together to
be considered identical," both because I don't want to deal with
date-parsing and because I don't want to make arbitrary decisions about
what "close enough together" means.
Thanks,
Jonathan Kamens
