At 2025-12-25T11:06:34-0800, Russ Allbery wrote:

quoted

Yup, I'd like that policy to change.  I've added debian-policy@ to
this mail (and also linux-man@).

The rationale in Debian for compressing documentation in general is
for embedded systems and other small installations, and it applies to
just about anything that can be safely compressed (manual pages are
only one example).  But this rule also predates such facilities as the
nodoc build profile, and is several decades old and thus predates the
growth in storage size even in small embedded environments that has
significantly outpaced the size of text-adjacent documents.  I would
definitely want to get feedback from embedded folks before changing
this rule, but at least at first glance it sounds like a reasonable
request worth considering.

I'd add that, in contrast to the mid-1990s when Debian's man page
compression policy was promulgated--my recollection is that it was an
early, early decision, already in place when I started using Debian in
January 1996--transparent compression is now an oft-implemented feature
of file systems, including some that are popular in embedded systems,
such as JFFS2, where it's been the case for at least 19 years.[1]

Further, the selection of compression algorithm and container format has
become a popular site for partisan battles over the same.[2][3][4][5][6]
Since Debian already generates sufficient partisan battles over issues
specific to our practices, it might be advantageous to abandon this one.
(Speaking for myself, I find deflate/gzip satisfactory, and I intend to
release groff 1.24.0 as a gzipped tape archive.)

Adopting this change would enable man-db man(1) to discard the
zsoelim(1) tool, simplifying the code base and logic depending on this
tool--but I defer to Colin's judgment of how advantageous that'd be.

Regards,
Branden

[1] https://lwn.net/Articles/219827/
[2] https://linuxreviews.org/Comparison_of_Compression_Algorithms
[3] https://www.nongnu.org/lzip/xz_inadequate.html
[4] https://engineering.fb.com/2016/08/31/core-infra/smaller-and-faster-data-compression-with-zstandard/
[5] https://www.reddit.com/r/archlinux/comments/eiia99/zst_packages_consistently_larger_than_xz/
[6] https://sysdfree.wordpress.com/2020/01/04/293/