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. > >> 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". -- WBR, wRAR
Attachment:
signature.asc
Description: PGP signature