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,
Cheers,
H.
> --
> WBR, wRAR
Reply to: