On Sun, Sep 11, 2022 at 03:09:07PM +0300, Hakan Bayındır wrote: > >>>> 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. I assume that cases when your dpkg database is broken and cases when you need to read changelogs of updated packages shouldn't intersect.
-- WBR, wRAR
signature.asc
Description: PGP signature
