Re: Automatic trimming of changelogs in binary packages
On 18/08/22 21:18, Gioele Barabucci wrote:
Does anybody have objective objections against activating automatic
changelog trimming in binary packages?
a couple of weeks since the initial email (thanks everybody for the
input), my reading is that there is now consensus in going ahead with
the proposed automatic trimming of changelogs.
## Addressed contrary objections
In particular, I understand that all contrary objections that were
raised have been satisfyingly addressed:
* Packages not meant to be included in Debian (and without access to a
changelog server): Creators that want to preserve the full history can
use the `--no-trim` option to disable the trimming.
* Third-party repositories: Their administrators can provide access to
the full changelogs by setting `Changelogs:` in the `Release` file, or
can use `--no-trim` in the packages that they distribute.
* Users should be made aware that changelogs have been trimmed:
`dh_installchangelogs` has been modified to add a comment at the end of
the trimmed changelogs.
* Source packages should retain full changelogs: This is, in fact,
already the case: only the changelogs included in the binary packages
* Reproducible output: Once trimming will be enabled in
`dh_installchangelogs`, either the changelogs will be trimmed (default)
or not (due to the explicit use of `--no-trim`). This ensures the
reproducibility of packages.
## Non-blocking concerns to be addressed in the future
In addition, there were concerns and ideas that were raised as non
blocking and that will be discussed and addressed in the future:
* Perhaps have dpkg treat changelogs as metadata: There are pros
(deduplication) and cons (the need to have a new command like `dpkg
* d-security has no online changelogs: Fixing this has been proposed in
2008 (https://bugs.debian.org/490848) but it did not seem to sparkle
enough interest at the time (and users of d-security are unlikely to be
interested in changelog entries older than old-old-stable).
* apt changelog could be instructed to choose between the local and the
remote changelogs, perhaps via options like `Changelogs::PreferOnline`
(to complement `AlwaysOnline`) and `--full`.
* Maybe the URLs used by the tracker to link to the changelogs and the
URLs used by apt to fetch the changelogs could be aligned.