doc (debhelper) compression: use bzip2?
I noticed that the Xorg (xorg-server) upstream changelog is starting to
get a bit large, ChangeLog.gz 341K.
How much sense would there be in using, say, bzip2 compression instead?
In this particular example that would reduce ChangeLog.bz2 to 251K, a
space saving of 26%.
A change like this would require updating Policy 12.7, and tools like
debhelper would need to be updated to take advantage of it.
For reference, the total sum of all /usr/share/doc/*/changelog.gz files
on my system is 43890 Kb (43 Mb). Using bzip2 might reduce that to
around 31Mb.
The largest changelog.gz (on my system, using 'find /usr/share/doc -name
changelog.gz -printf "%s %p\n" | sort -nr' ) come from
wine (12 packages) 558 Kb
lynx 341 Kb
debian-keyring 286
cmake 280
hal (4 packages) 280
libdirectfb-0.9-25 264
gnome-vfs2 (4 packages) 256
apache2 (3 packages) 230
dia-common 220
libcairo2 (3 packages) 214
gnash (2 packages) 201
gnash-tools 201
libgnash0 201
libsablevm-classlib1 (2 packages) 201
libsablevm-native1 201
pwlib (4 packages) 200
etc. etc.
Of course, changing compression policy would also reduce the size of
other compressed doc files than just changelog.gz.
I'm not sure if it's really worth it, especially since not every package
has changelogs the size of Xorg's or wine's (hence I'm not filing a bug
about it), but I thought it might be interesting to raise the question
to see what others think.
Drew
p.s. for reference, previous discussions on package compression (not doc
compression) were made at
http://lists.debian.org/debian-devel/2005/12/msg00759.html
and
http://lists.debian.org/debian-devel/2007/04/msg00291.html
The difference of course concerns the storage size of the archive vs.
the storage size of an installed system.
Reply to: