Re: Automatic trimming of changelogs in binary packages
> On 11 Sep 2022, at 14:59, Andrey Rahmatullin <wrar@debian.org> wrote:
>
> On Sun, Sep 11, 2022 at 02:41:24PM +0300, Hakan Bayındır 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.
> It didn't create anything because that was how it worked from the
> beginning.
> But yes, it's easier to run -q --changelog than write a full file path.
While I manage RPM based systems too, I’m not that familiar with depths of RPM.
>
>>>> 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.
> Even this isn't "making them online only".
Yes, you’re right. However, my reservation is whether dpkg is more prone to breaking in disaster recovery scenarios. Reading a gzipped file is always simpler than querying a DB via more abstraction.
Cheers,
H.
> --
> WBR, wRAR
Reply to: