Re: [gentoo-dev] bzipped manpages
On Jan 10 14:16:47, grob...@gentoo.org wrote: > On 09-01-2017 09:08:22 +0100, Jan Stary wrote: > > The particular problem I am having is that http://mdocml.bsd.lv/ , > > my manpage formatter of choice, does deliberately not support bzip > > (or any other outside decompressors for that matter). > > Attached patch works for me. Works for me too, thanks. Jan
Re: [gentoo-dev] bzipped manpages
On Jan 11 13:34:09, sven.e...@gmx.de wrote: > Am Dienstag, 10. Januar 2017, 13:36:15 CET schrieb Jan Stary: > > > You arguing that 40MB is nothing on modern systems (which, by the way is > > > not exactly true, talking about embedded ones). > > > > Can you gove an example of an embedded system with manpages? > > My Raspberry Pi 3. ;-) How is that an embedded system? It's a full blown linux installation.
[gentoo-dev] bzipped manpages
This is Gentoo 2.2 (4.4.6-gentoo x86_64).
The system manpages seem to be bzipped as in
/usr/share/man/man1/ls.1.bz2
Why is that? Is there any benefit to compressing the manpages nowadays?
IMHO it only adds a layer of complexity, for very questionable benefit
(i.e. disk space): how much of the overal system do _manpages_ take?
The particular problem I am having is that http://mdocml.bsd.lv/ ,
my manpage formatter of choice, does deliberately not support bzip
(or any other outside decompressors for that matter).
Would you please consider distributing plain *.{123456789} manpages
and getting rid of the bzip layer?
Thank you
Jan
> I am using mdocml on other systems beside OpenBSD.
> On most linuxes, it works just fine, including gzipped manpages
> such as /usr/share/man/man1/ls.1.gz od Debian.
>
> Now I found myself on a Gentoo linux, where manpages are bzipped,
> like /usr/share/man/man1/ls.1.bz2; on this system man(1) displays
> what seems to be the verbatim 'bz2' file, unbziped (attached).
> See below for the out put of 'man ls'.
>
> Is it because mdocml does not support bzip?
Yes. Neither does it support piping through external unpackers.
> If so, should man rather fail than display the page?
No. It's a feature that mandoc(1) and man(1) never fail, no matter
what the input is. It is a convenience for arbitrary, very serious
bugs in otherwise half-sane manuals. I spent a lot of time archieving
that feature. It is not a security risk even when you do garbage
in - garbage out. It still doesn't write to disk, it still doesn't
access arbitrary files, it still doesn't print control codes to the
terminal - you see all those harmless question marks in there?
> I don't know why any system would bzip it's manpages,
> but apparently Gentoo does.
Exactly. It is completely stupid nowadays. Just tell them to stop
doing such nonsense and install uncompressed. Manual pages are small
compared to libraries:
schwarze@isnote $ du -sk /usr/share/man
40472 /usr/share/man
schwarze@isnote $ du -sk /usr/lib
229516 /usr/lib
schwarze@isnote $ du -sk /usr/local/man
50022 /usr/local/man
schwarze@isnote $ du -sk /usr/local/lib
2576778 /usr/local/lib
That's *uncompressed* mind you, and extensive, high quality OpenBSD
manuals. Tell me, which system is unable to afford 100 Megabyte
of disk space for manual pages? In this day and age? An embedded
system? Right, you certainly have manual pages there.
Compressing that stuff just makes life harder for absolutely no benefit
whatsoever.
> Are there any plans to support bzip beside the ubuquituous gzip?
> (I understand if you don't want that in your code.)
No plans, and some opposition to trying.
Even supporting *.gz is kind of stupid, but that stupidy is widespread
enough that i bowed to the pressure. It's implemented in the safest
possible way by linking directly against the time proven and no
longer much changing libz. I'm very reluctant to resurrect the
code to spawn external decompressors - even in portable mandoc.
It is messy and potentially risky.
So, you want to hear something constructive? Your best option is to
just decompress that stuff on your system. (Gentoo is famous for
its excessive configurability - maybe there is even an option?)
Otherwise, you can set up a small shell script to recursive run
bunzip2(1) across the directories in question and run it whenever
you are shown garbage after installing new stuff. Bonus: Manuals
never get deleted even after uninstalling stuff, so you can still
look things up to find out whether it might be worth reinstalling
a package that you once had.
If you are unable or unwilling to do that, just use a different
man(1) implementation and use mandoc(1) the traditional way as a
groff drop-in replacement. All you lose that way is apropos(1).
Yours,
Ingo
Re: [gentoo-dev] bzipped manpages
On Jan 10 19:19:03, gen...@mva.name wrote: > В письме от вторник, 10 января 2017 г. 13:08:14 +07 пользователь Jan Stary > написал: > > On Jan 10 19:04:47, gen...@mva.name wrote: > > > > There is an option to support; the packages need to be reinstalled > > > > or there are untracked files; the manpage formatter needs to call > > > > external unpackers. All this to save 40M. I honestly don't think > > > > it's worth it. > > > > > > Why do you care about calling external unpacker, > > > but do not care about saving 40MB? > > > > Because not having to call an external unpacker > > allows for the manpage formatter to be simple; > > whereas saving 40M of space is of no concern. > > You arguing that 40MB is nothing on modern systems (which, by the way is not > exactly true, talking about embedded ones). Can you gove an example of an embedded system with manpages? > So, I guess, it means, that you have modern powerfull hardware, which is > pretty fine with some overheads. If having an extra 40MB is "modern, powerfull hardware", then yes. > Then why do you need "simple" manpage formatter? Why do I want software to be simple? > And actually, why calling external unpacker is so complicated? Almost any > programming language I know, has functions identical to C's system()... It's not that complicated; it's unneeded, it's another dependency, etc. > Do you fully understand, that you asking to change "defaults", that will > affect tons of users (which are happy with current "defaults") because yours > only own local problems (not having root access on the system)? This has nothing to do with not having root - that only makes it unable for me to use the _workarounds_. What would be the effect of having uncompressed manpages as the default? (Besides having them renderred by any manpage formatter, and wasting 40MB of space, obviously)? Jan
Re: [gentoo-dev] bzipped manpages
On Jan 10 12:54:21, h...@stare.cz wrote: > Also, the uncompressed manpage will not get updated > when the packages gets updated. I will have two copies, > a stale *.1 and an up-to-date *.1.bz2. And things like /usr/share/man/man1/sx.1.bz2 will not get unbzipped, because it's a symlink, now broken. So a special care needs to be taken of the _names_ of these. Jan
Re: [gentoo-dev] bzipped manpages
On Jan 10 19:04:47, gen...@mva.name wrote: > > There is an option to support; the packages need to be reinstalled > > or there are untracked files; the manpage formatter needs to call > > external unpackers. All this to save 40M. I honestly don't think > > it's worth it. > > Why do you care about calling external unpacker, > but do not care about saving 40MB? Because not having to call an external unpacker allows for the manpage formatter to be simple; whereas saving 40M of space is of no concern.
Re: [gentoo-dev] bzipped manpages
On Jan 09 09:30:11, ike...@gentoo.org wrote: > Hiya Jan, > > The following snippet from Ingo is correct: > > > So, you want to hear something constructive? Your best option is to > > just decompress that stuff on your system. (Gentoo is famous for > > its excessive configurability - maybe there is even an option?) > > We are both famous for our excessive configurability and there is even > an option already! 5:) If you look in the manpage (once you've > decompress it somewhere, or online at [1]) for make.conf, you'll see the > entry for PORTAGE_COMPRESS, which you can set as follows: > > PORTAGE_COMPRESS="" I am only a user on this system, and have no control over which packages are installed and have no write permissions in /usr/share/man/ or make.conf > As mentioned in [2,3,others]. You'll then need to reinstall all > packages. If you manually decompress the files, then the uncompressed > manpages won't be registered with portage and won't get removed if the > owning package is uninstalled. Also, the uncompressed manpage will not get updated when the packages gets updated. I will have two copies, a stale *.1 and an up-to-date *.1.bz2. These are workarounds. Let me get back to the original question: would you please consider having _uncompressed_ manpages as the default? On this particular system, the bzipped /usr/share/man/ is 67M. The uncompressed man/ is 108M. That's 40M saved. Seriously? There is an option to support; the packages need to be reinstalled or there are untracked files; the manpage formatter needs to call external unpackers. All this to save 40M. I honestly don't think it's worth it. Jan
Re: [gentoo-dev] bzipped manpages
> > This is Gentoo 2.2 (4.4.6-gentoo x86_64). > > That doesn't actually tell any Gentoo user anything about your system > except a very specific few bits of data which do not relate at all to > the rest of the subject matter of your e-mail. I am not really familiar eith this system - what would be the right piece of information that does relate tot this? > [1] echo 'PORTAGE_COMPRESS=""' >> /etc/portage/make.conf -ksh: /etc/portage/make.conf: cannot create [Permission denied] Jan
