[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Automatic trimming of changelogs in binary packages

Hi Andrey,

> On 6 Sep 2022, at 12:42, Andrey Rahmatullin <wrar@debian.org> wrote:
> On Tue, Sep 06, 2022 at 12:11:38PM +0300, Hakan Bayındır wrote:
>> 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.
> Assuming you are talking about making changelogs available at a dpkg
> command, as in the RPM world, it's actually making the way to get a
> package changelog more well-known, not less.

If this created the opposite effect in RPM world w.r.t. my theory, then I stand corrected.

>> 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.
> I don't think removing recent-ish changelogs from the disk is proposed
> here.

Again, I may have misread, then. Because what I understood is

Trim changelogs:
1. Convert them to metadata
2. Ship untrimmed part in package DB
3. Get remaining part from network

Effectively eliminating /usr/share/doc/*changelog* files.

Thanks for clarifying both,



> -- 

Reply to: