discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: Aisha Tammy <openbsd@aisha.cc>
Cc: discuss@mandoc.bsd.lv
Subject: Re: Possible to add optional bzip2 support?
Date: Sun, 29 Nov 2020 21:14:24 +0100	[thread overview]
Message-ID: <20201129201424.GI58187@athene.usta.de> (raw)
In-Reply-To: <d5e55c57-002a-e654-b7c2-dca9fb84863d@aisha.cc>

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


       reply	other threads:[~2020-11-29 20:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <d5e55c57-002a-e654-b7c2-dca9fb84863d@aisha.cc>
2020-11-29 20:14 ` Ingo Schwarze [this message]
2020-11-29 21:07   ` Jan Stary
2020-11-29 21:41   ` Aisha Tammy
2020-11-29 22:24   ` Kazuo Kuroi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201129201424.GI58187@athene.usta.de \
    --to=schwarze@usta.de \
    --cc=discuss@mandoc.bsd.lv \
    --cc=openbsd@aisha.cc \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).