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

Re: Automatic trimming of changelogs in binary packages

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
But yes, it's easier to run -q --changelog than write a full file path.

> >> 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".


Attachment: signature.asc
Description: PGP signature

Reply to: