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.
- Panu -
*HYPOTHETICAL* command ideas:
dnf install --no-man-pages coreutils tmux sl
dnf install --no-man-pages --no-info-pages gcc make
dnf upgrade --no-man-pages coreutils
dnf upgrade --man-pages gcc
You get the idea.
--
_______________________________________________
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
