From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14086 invoked from network); 29 Nov 2020 20:14:31 -0000 Received: from bsd.lv (HELO mandoc.bsd.lv) (66.111.2.12) by inbox.vuxu.org with ESMTPUTF8; 29 Nov 2020 20:14:31 -0000 Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 234bea46 for ; Sun, 29 Nov 2020 15:14:29 -0500 (EST) Received: from scc-mailout-kit-01.scc.kit.edu (scc-mailout-kit-01.scc.kit.edu [129.13.231.81]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 0661f0d2 for ; Sun, 29 Nov 2020 15:14:28 -0500 (EST) Received: from hekate.asta.kit.edu ([141.3.145.153] helo=hekate.usta.de) by scc-mailout-kit-01.scc.kit.edu with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (envelope-from ) id 1kjT5V-0001sP-N2; Sun, 29 Nov 2020 21:14:26 +0100 Received: from donnerwolke.asta.kit.edu ([141.3.145.61] helo=donnerwolke.usta.de) by hekate.usta.de with esmtp (Exim 4.92.2) (envelope-from ) id 1kjT5U-0004yw-Fv; Sun, 29 Nov 2020 21:14:24 +0100 Received: from athene.asta.kit.edu ([141.3.145.60] helo=athene.usta.de) by donnerwolke.usta.de with esmtp (Exim 4.84_2) (envelope-from ) id 1kjT5U-0007gE-9n; Sun, 29 Nov 2020 21:14:24 +0100 Received: from localhost (athene.usta.de [local]) by athene.usta.de (OpenSMTPD) with ESMTPA id bddc162b; Sun, 29 Nov 2020 21:14:24 +0100 (CET) Date: Sun, 29 Nov 2020 21:14:24 +0100 From: Ingo Schwarze To: Aisha Tammy Cc: discuss@mandoc.bsd.lv Subject: Re: Possible to add optional bzip2 support? Message-ID: <20201129201424.GI58187@athene.usta.de> References: X-Mailinglist: mandoc-discuss Reply-To: discuss@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Hi Aisha, Aisha Tammy wrote on Sun, Nov 29, 2020 at 10:37:44AM -0500: > I'm trying to get Gentoo to add mandoc as an alternative man provider > as an optional replacement for the current man-db. Currently, we only allow > man-db as the man provider. I've successfully managed to get the changes > and have already made the PR (hopefully, barring anything extra ordinary, it > should go through). Nice, thanks. > Currently, we compress all our man pages with bzip2 by default Why? Compressing manual pages makes absolutely no sense to me in 2020. This is on one of my desktop machines where i have large amounts of cruft installed for testing: $ du -sh /usr/share/man /usr/X11R6/man /usr/local/man 41.8M /usr/share/man 9.0M /usr/X11R6/man 69.9M /usr/local/man Here are a few other directories for comparison: 88.3M /usr/local/share/emacs 71.2M /usr/local/share/gtk-doc 209M /usr/local/share/doc 273M /usr/local/share/locale 209M /usr/local/lib/firefox 218M /usr/local/lib/thunderbird 609M /usr/local/lib/libreoffice So all the manual pages on a system, even if they are uncompressed and even if a lot of stuff is installed, typically need a small fraction of the space needed by a single modern application program. Asked the other way around, who cares, in 2020, about 0.05 GB of disk space on the /usr/ partition? Or even, when installing insane amounts of optional software, about maybe 0.2 or so GB? How are such totally negligible gains worth any kind of trouble? Sometimes, people told me "but we want to install unchanged on embedded systems and there 50 MB are a big deal". I have a hard time believing that. If a given embedded system really has trouble with disk space for 50 MB of manual pages, then it is virtually certain that you cannot install a modern general-purpose operating system to it without changes in the first place. And it almost certainly isn't a system where users want to log in interactively and read manual pages. > and none of them are usable with mandoc, a small amount of scripting > is needed to recompress all man pages and this also messes up the > package manager and over all is a bit ugly. I am unsure how bad/hard > it is to add bzip2 support but is there any hope of it being > added as an option? even if it is not available by default? It would be easier to convince me to delete *.gz support than to add *.bz2 support. Either is unrelated to the purpose of mandoc and linking to zlib is ugly and messy, i'd love to get rid of the dependency and of the rather ugly and error-prone code needed to support *.gz files. Regarding *.bz2 in particular, i see very little chance to get /usr/lib/libbz2.so.*.* added to the OpenBSD base system. Regarding options, i think options are evil in general. If you want an option, you need very good arguments why the feature is useful to such an ususual degree that it justifies an option. Here, i don't see any benefit at all to offset the cost in dependencies, complexity, and maintenance. Yours, Ingo -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv