Web lists-archives.com

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
PGP/GPG: 4096R/6C6ACD6417B3ACB1