Re: Limiting the size of installed changelogs
- Date: Thu, 13 Sep 2018 13:12:04 +0200
- From: Adam Borowski <kilobyte@xxxxxxxxxx>
- Subject: Re: Limiting the size of installed changelogs
On Thu, Sep 13, 2018 at 11:22:37AM +0100, Ben Hutchings wrote:
> The src:linux package has a very big changelog (about 1700 kiB
> uncompressed, 600 kiB gzipped). On my system the largest installed
> changelogs, by some way, are all versions of this. (The next largest
> changelogs come from src:glibc, at about 200 kiB gzipped.)
> The older history is unlikely to be of any use to users. So on smaller
> systems this could be a significant waste of space.
> - Would it make sense to split the changelog, leaving older entries
> only in the source package? If so, should this be done manually, or
> would it make sense to have dh_installchangelogs split at some age or
> size limit?
Most packages don't have such a volume of changes, so manual would be ok.
If there's any automation, it would need to handle _both_ age and size,
as a size limit appropriate for almost any other package would cut the
kernel too short -- we'd want changes at least until oldstable.
> - Does it make sense to compress changelogs with xz? For src:linux,
> this achieves about a 20-25% reduction over gzip.
I gave it a try -- and it appears that, after excluding changelogs over 64KB
gzipped, gzip->xz reduced the total size only from 20M to 19M. Not worth
the hassle -- xz has a slow start.
So trimming largest changelogs would be enough.
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17]
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37]
⠈⠳⣄⠀⠀⠀⠀ • use glitches to walk on water [Mt14:25-26]