Re: Limiting the size of installed changelogs
- Date: Thu, 13 Sep 2018 21:28:20 +0900
- From: Roger Shimizu <rogershimizu@xxxxxxxxx>
- Subject: Re: Limiting the size of installed changelogs
On Thu, Sep 13, 2018 at 7:22 PM, Ben Hutchings <ben@xxxxxxxxxxxxxxx> 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.)
Makes full sense.
Especially sometimes you need to have at least two kernels on system:
the one is running and another security updated new one.
While SSD is still expensive, saving storage is always welcome.
> I recently had to introduce yet more installed copies of this changelog
> because the case where we used linked doc directories is no longer
> valid (arch-dependent package became arch-independent).
> The older history is unlikely to be of any use to users. So on smaller
> systems this could be a significant waste of space. (I know it's
> possible to filter out the installation of docs entirely, but I don't
> think this option is well known.)
> - A large part of the changelog is listing the changes in upstream
> stable updates. These are mostly important changes, and we already try
> to leave out those that are clearly irrelevant to Debian. Should we
> continue to include these, or limit to those that address CVEs or
> Debian bug reports?
> - 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?
I think it should at least contain the content of one release cycle. (or two?)
E.g. When Buster get released, we sometimes need to check what's been
changed since Stretch.
> - Does it make sense to compress changelogs with xz? For src:linux,
> this achieves about a 20-25% reduction over gzip.
If there's not much difference when uncompressing xz, I guess it's
good idea to switch to xz for Buster.
Thanks for your idea!
Roger Shimizu, GMT +9 Tokyo