On 12/9/25 9:30 AM, Panu Matilainen wrote: > On 12/5/25 9:21 PM, Dave Cantrell 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. >> >> I would rather us do away with compressed man pages entirely. What would be >> really nice if we had an option on rpm (and by extension dnf) to say >> "install this package, but I don't want any man pages from it". Perhaps >> even a site-wide option in dnf.conf too. They wouldn't land on the >> installed system, the rpmdb would be fine, and it could be maintained >> through package upgrades. You could even go further and add an option to >> dnf that says "on second thought, I do want man pages....(for everything|but >> just for <this package>)". Doing that would also avoid having to create >> yet-more-packages, like man page subpackages. The advantages I see here are >> that you can have all the man pages you want, but we would introduce easy >> tooling that would allow you to "opt out" of man pages when setting up a >> system. Lean images, and so on. Shave the yak, but just in a slightly >> different way. But that's just me. >> >> How would rpm know what to do? Well we could come up with a marker for man >> pages (and info pages) using rpmfileAttrs. Like rpm has RPMFILE_DOC now and >> RPMFILE_README and RPMFILE_LICENSE. Though I brought that up years ago and >> it was rejected. Could use libmagic. Or we could more broadly say >> "anything installed in %{_mandir} is a man page" and so on. Point is, there >> are a number of ways to implement this in the package tooling without having >> to create more packages and or bigger spec files and I think it would be a >> nice way to both keep man pages but allow for building systems without the >> extra baggage when you want something extra lean. >> (Also applies to info pages!) >> > > Technically, rpm does support this for arbitrary paths since forever > (and I mean 4.0 or older forever): > > [root@lumikko tmp]# rpm -U --excludepath=/usr/share/man > telnet-0.17-95.fc43.x86_64.rpm > [root@lumikko tmp]# rpm -Vv telnet > ......... /usr/bin/telnet > ......... a /usr/lib/.build-id > ......... a /usr/lib/.build-id/f0 > ......... a /usr/lib/.build-id/f0/d90d7a7dca05d76fb36514748fc36c0a997be2 > ......... /usr/share/doc/telnet > ......... d /usr/share/doc/telnet/README > ......... d /usr/share/man/man1/telnet.1.gz (not installed) > > ...but this uses the relocation "API" that nothing but rpm itself ever > used. There's also %_netsharedpath configurable which also achieves not > installing files, the difference is that rpm then expects *something* to > have put those files in there, otherwise they'll be reported as missing > on verify.
Right, but what I was wanting was for complete support for doing that so that things like --verify work. Also, for a user to be able to bring in not-installed files later if they want to. Possibly more explicit integration in higher up tools like dnf. But yeah, doing this is not difficult. I also want to think about packaging policy in addition to the tooling, which is where my brain was going for a lot of what I said. -- Dave Cantrell <[email protected]> Red Hat, Inc. | Boston, MA | EST5EDT -- _______________________________________________ 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
