On Fri, Dec 5, 2025 at 4:11 PM Dave Cantrell <[email protected]> wrote: > > On 12/5/25 15:47, Neal Gompa wrote: > > On Fri, Dec 5, 2025 at 2:20 PM Dave Cantrell <[email protected]> wrote: > >> > >> On 11/28/25 13:07, Neal Gompa wrote: > >>> Hey folks, > >>> > >>> This has been percolating in my mind for a little while now, but we've > >>> been going through and switching things to zstd across the board (most > >>> recently initramfs, but we did btrfs compression, zram, and even rpm > >>> previously), and I wonder if we want to also switch man and info pages > >>> from gzip to zstd. > >>> > >>> This has already been done at least once with OpenMandriva, so I know > >>> it is possible with an RPM distribution in a reasonable fashion. > >>> > >>> At least man-db has support for zstd compression and just needs to be > >>> told to prefer it at build time, and OpenMandriva has a patch for > >>> texinfo[1]. If we want to do it, it's not hard to accomplish > >>> > >>> Is there a compelling reason that we shouldn't consider migrating to > >>> zstd in an upcoming Fedora release? > >>> > >>> > >>> [1]: > >>> https://github.com/OpenMandrivaAssociation/texinfo/blob/master/texinfo-6.7-zstd-compression.patch > >>> > >>> > >> > >> I personally do not see the point in compressed man pages anymore. A long > >> time ago we would preformat man pages too since doing that was resource > >> intensive and even Linux systems had both man pages and catman pages. But > >> we don't need any of that these days. > > > > It is tempting, but the usage of Linux on really constrained systems > > (such as single board computers) are still extremely common, so I > > think there's still value in compression. And it is also becoming more > > common to make larger and wordier man pages, rather than splitting > > them into separate help tooling. The compression helps a little bit > > with that. I think it's definitely valuable for info pages, which are > > often huge. > > > > (As an aside, I *barely* remember the time when we preformatted man > > pages, that was already going away by the time I started to use > > Linux...) > Constrained systems are a reasonable concern, but which ones out there now > have storage constraints where changing the compression used on man pages > would help? I ask because I really don't know. > > On my workstation I made a copy of /usr/share/man and removed all of the > symlinks in that tree. There are 39163 man pages in that directory. I made > two copies. The first to uncompress the pages and the second to compress > them all with zstd. Here's the storage results I gathered from 'du -s -h': > > default/ 182M > uncompressed/ 294M > zstd/ 182M > > Other comparisons: > /usr/share/doc 439M > /usr/share/licenses 47M > > At least on my system, changing the man pages to zstd makes no difference. > But keeping them compressed saves me 112M. Are there really systems where > something like 112M is a concern? I also have 3504 packages installed on my > workstation, so I sort of expect to be using storage space. >
Yes, unfortunately. Especially when you multiply it with containers and other things that have become more common now. At least Fedora's default setup doesn't have space contention issues like it used to, but people still put Fedora on small SD cards for these things... > If we make this change, we run the risk of breaking man page symlinks. > Rather than using ".so" man page references that we could compress the same > way as man pages, we have symlinks to the compressed form of the target man > page. So, take gawk for example. We have /usr/share/man/man1/awk.1.gz which > is a symlink to /usr/share/man/man1/gawk.1.gz. A cleaner method to me is to > install /usr/share/man/man1/gawk.1 and then do this for awk.1: > > echo ".so man1/gawk.1" > /usr/share/man/man1/awk.1 > > Then you can compress *.1 in the package building process and not have to > have a more complicated loop that figures out the symlink farm. > > I would still prefer uncompressed man pages. If we were to still compress > them, I would prefer to keep the file ending consistent regardless of the > compression format used and make man(1) deal with that transparently. > > But all of that aside, if space constrained systems is a concern, having a > way to keep man pages but exclude /usr/share/doc would save more space. > Finer-grain control on --nodocs. > To be fair, we should probably document (or create a macro) for man page symlinks. I do it correctly for pkgconf and other packages I maintain where it's needed, but not many people know about this. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
