Hello,
in 2020 there was a brief discussion on debian-devel@ about trimming
changelogs [1,2].
Now there is a working implementation of said functionality in
`dh_installchangelogs` [3].
This implementation, combined with the evolution of the apt/dpkg
ecosystem that happened in the meantime, provides now all the benefits
of changelog trimming (less wasted space and bandwidth worldwide,
reduced processing time) without the downsides discussed at the time.
## In detail
* `dh_installchangelogs` is modified install in binary packages the
trimmed changelogs, i.e. changelogs that contain only entries more
recent than the release date of oldstable.
* The trimming is done automatically in compat >= 14.
* The `--no-trim` option allows package maintainers that want to ship
the whole changelog a way to do so.
* The full changelogs are preserved in the source packages and thus
available via `apt changelog` and similar mechanisms.
* The trimming process happens at build time and requires no
modification to the changelogs stored in the VCS repos, nor changes to
the packaging.
## Data on file size reduction
On a sample of ~13.000 packages, the median reduction in size of
gzip-9'ed changelogs is 56% (mean 50%).
Ancient packages or heavily developed packages gain a lot from trimming
the changelogs. Some examples (gzipped → trimmed+gzipped):
* debian-keyring: 664k → 47k (-92%)
* dpkg (essential): 223k → 22k (-90%)
* apt (essential): 156k → 14k (-90%)
* systemd: 110k → 23k (-78%)
* gcc-12: 189k → 18k (-90%)
* python3.9: 48k → 4k (-90%)
* e2fsprogs: 68k → 7k (-89%)
## Consensus
Does anybody have objective objections against activating automatic
changelog trimming in binary packages?
Regards,
[1] https://lists.debian.org/debian-devel/2020/03/msg00299.html
[2] https://bugs.debian.org/954313
[3] https://salsa.debian.org/debian/debhelper/-/merge_requests/80
--
Gioele Barabucci
