Hi Jonathan (2023.09.26_10:11:01_+0000) > I am hoping that this is an acceptable request to make of the > technical committee
Absolutely. In this case, I doubt the committee needs to offer any formal advice. These are my personal views, after only a few minutes of thought. > That bug prompted me to do a deep dive into the algorithm that > apt-listchanges uses to determine which changelog and NEWS entries to > display to the user. After doing that, I don't tihnk the current > algorithm is accurate enough, and I want to revamp it. Thanks for taking on a much bigger job than you probably expected to have signed up for :) > For an example of where these assumptions break down, look at the > dmsetup package: > > - The source package for dmsetup is lvm2. > - The version number for the dmsetup package is lower, but with a > higher epoch than, the version number for the lvm2 package. > - The entries in changelog.Debian.gz use lvm2 version numbers, while > the ones in changelog.Debian.devmapper.gz use dmsetup version > numbers. > > This approach was also limited in that it only looked at > NEWS.Debian[.gz], changelog.Debian[.gz], changlog.Debian.arch[.gz], > and changelog[.gz]. For an example of where this fails, again look at > dmsetup, which has changelog.Debian.devmapper.gz. 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? > We remove the header line of each entry in the second set of checksums > because sometimes a package version uploaded to stable and a different > version uploaded to unstable use different header lines for the same > changelog entry. I can see the logic for that. You could also argue that when a package is uploaded to multiple releases (with different versions, of course), these are forks. And when jumping from one fork to another it's reasonable to include the repeated changelog content. But yes, in most cases hiding text that a user has already seen is probably correct. Unless they need to take some action that's specific to the version of the package that this text appears in (e.g. introduce versioned Depends in their own packages), which is very rare. Please correct me if I'm wrong in any of my analysis. 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? Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
