Re: Possible to add optional bzip2 support?

Re: Possible to add optional bzip2 support?

[Ingo Schwarze]

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

Re: Possible to add optional bzip2 support?

[Jan Stary]

Hi Ingo,

On Nov 29 21:14:24, schwarze@usta.de wrote:
> 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.

would you please kindly consider removing the gz support from mandoc?
The linking is messy, the code needed to support *.gz files is rather
ugly and error-prone, and the (un)compression is unrelated to the
purpose of mandoc in the first place.

	Jan

--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv

Re: Possible to add optional bzip2 support?

[Aisha Tammy]

On 11/29/20 3:14 PM, Ingo Schwarze wrote:
> 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.

HAHA!! This is exactly what I expected, down to the T :D
And I am not saying this maliciously AT ALL, this is what I 
my feelings were, albeit on the fence.
Just wanted to ask in the off chance that somehow, magically, this
was a sane option (its not) :P

> 
>> 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.
> 

These are all perfectly valid reasons and I agree.
I agree with not needing this and am totally fine without it :)

Thanks a lot!
Aisha

PS: Would it be possible to get a minor(or whatever) release to address the
bug fixes (iirc html fixes were some) and building with gcc-10 ?

> Yours,
>   Ingo
> 
--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv

Re: Possible to add optional bzip2 support?

[Kazuo Kuroi]

I'm not party to this discussion directly, but if we're discussing 
compression methods, maybe a completely different (simple, clean to 
implement) compression method is called for to replace both bzip and 
gzip in this capacity? I dunno. That's just my POV from the outside in. 
LZ4 perhaps? That's OpenBSD-compatible license-wise, though I know Theo 
is very much a bit of a curmudgeon on things like this.

Shrug. I hope a compromise can be achieved.

On 11/29/2020 3:14 PM, Ingo Schwarze wrote:
> 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
>
--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv