Bug#1052697: tech-ctte: proposed change to apt-listchanges algorithm needs expert consideration
On Tue, 26 Sep 2023 at 06:11:01 -0400, Jonathan Kamens wrote:
> This approach was based on two assumptions, neither of which is always
> true:
>
> 1. Assume that the version numbering for all packages that come from
> the same source package are in the same series.
> 2. Assume that the version numbering of entries always matches the
> aforementioned version numbering.
>
> 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.
It is possible to ask dpkg for the name *and version* of the source
package from which a binary package was built. For example:
$ dpkg-query -W dbus
dbus 1.14.10-1
$ dpkg-query -W -f '${Source}\n' dbus
$ dpkg-query -W dbus-daemon
dbus-daemon 1.14.10-1
$ dpkg-query -W -f '${Source}\n' dbus-daemon
dbus
$ dpkg-query -W dmsetup
dmsetup 2:1.02.185-2
$ dpkg-query -W -f '${Source}\n' dmsetup
lvm2 (2.03.16-2)
The source package as defaults to the binary package and the source
version defaults to the binary version, so in this example we have:
- binary: dbus_1.14.10-1 -> source: dbus_1.14.10-1
- binary: dbus-daemon_1.14.10-1 -> source: dbus_1.14.10-1
- binary: dmsetup_2:1.02.185-2 -> source: lvm2_2.03.16-2
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.
(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.)
smcv
Reply to: