* Re: Possible to add optional bzip2 support?
2020-11-29 20:14 ` Possible to add optional bzip2 support? Ingo Schwarze
@ 2020-11-29 21:07 ` Jan Stary
2020-11-29 21:41 ` Aisha Tammy
2020-11-29 22:24 ` Kazuo Kuroi
2 siblings, 0 replies; 4+ messages in thread
From: Jan Stary @ 2020-11-29 21:07 UTC (permalink / raw)
To: discuss
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Possible to add optional bzip2 support?
2020-11-29 20:14 ` Possible to add optional bzip2 support? Ingo Schwarze
2020-11-29 21:07 ` Jan Stary
@ 2020-11-29 21:41 ` Aisha Tammy
2020-11-29 22:24 ` Kazuo Kuroi
2 siblings, 0 replies; 4+ messages in thread
From: Aisha Tammy @ 2020-11-29 21:41 UTC (permalink / raw)
To: Ingo Schwarze; +Cc: discuss
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Possible to add optional bzip2 support?
2020-11-29 20:14 ` Possible to add optional bzip2 support? Ingo Schwarze
2020-11-29 21:07 ` Jan Stary
2020-11-29 21:41 ` Aisha Tammy
@ 2020-11-29 22:24 ` Kazuo Kuroi
2 siblings, 0 replies; 4+ messages in thread
From: Kazuo Kuroi @ 2020-11-29 22:24 UTC (permalink / raw)
To: discuss
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
^ permalink raw reply [flat|nested] 4+ messages in thread