On Thu, Sep 13, 2018 at 7:22 PM, Ben Hutchings <b...@decadent.org.uk> 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! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1