Hello all,While all looks good and feels sound from many aspects, I have some reservations against treating changelogs as metadata.
Current changelogs as files have a well known place, can be used by anything and everything, and they are local.
Stuffing them behind a command, possibly making them online only in the process will arguably make system troubleshooting and administration harder, esp. if the system has connectivity issues.
If something critical breaks, I can boot to recovery and look at the logs and changelogs of recently updated packages. Having recent-ish changelogs on the disk arguably accelerates the fixing process.
Not expanding the tools and capabilities required to do system maintenance and disaster recovery is a good target to have if you ask me.
Cheers, Hakan On 6.09.2022 08:13, Gioele Barabucci wrote:
On 18/08/22 21:18, Gioele Barabucci wrote:Does anybody have objective objections against activating automatic changelog trimming in binary packages?Hi,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 objectionsIn 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 are trimmed.* 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 futureIn 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 --show-changelog`).* 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.Regards, -- Gioele Barabucci
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature