[haiku] Re: Man
- From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
- To: <haiku@xxxxxxxxxxxxx>
- Date: Wed, 25 Aug 2010 09:55:57 +0200
Am Mittwoch, den 25.08.2010, 08:57 +0200 schrieb Truls Becken
<truls.becken@xxxxxxxxx>:
> On 2010-08-24, at 21:54, Dave Osbourne wrote:
>
>>> Haiku comes with a bunch of man pages, but no man command.
>>> Is this on purpose?
>>
>> I believe you can use troff -n or something like that as an alias instead.
>
> Except *roff is not installed either. ;)
>
> I think it is a good idea to decide on what types of files should be
> included from ports. Even for optional packages.
Exactly! We need to make a decision about which format should be our
console
documentation format (man, info or html). The big thing is *not* that
we would
then require an application that can server this format, the big thing
is that
we will have to change all optional packages to provide the
documentation in
that format (and leave out the others). I personally have tried to
provide html
documentation in the optional packages I built and taken care to remove
info- and
man-files.
If we really should decide in favour of html, we would need a terminal
browser
available by default (or do we already have one?). We could install a
symlink to
that browser named 'man', too :-)
> E.g: Should info files and/or man pages be included? What about
> readme and license files scattered all over the system? Could they be
> cleaned up? /boot/{system,common}/data/licenses holds all relevant
> licenses.
>
> Guidelines on how "clean" packages should be would be good. For
> instance, Vision installs LICENSE.Makefile, which is certainly useless
> to the end user, and cdrtools comes with readmes for OS X and Solaris.
Right. Of course, packages should be clean, i.e. with as little
irrelevant info as
possible. There should be *one* set of documentation files, packages
should *not*
provide formats that the default haiku system can't deal with. If there
are
packages which have no provisions for creating the haiku's
documentation format
(whatever we will pick), there should be a guideline on how to create
that format
from given man/info documentation. Tools like man2html, texinfo, etc.
generate
output with differing structure and levels of detail. It would be great
to
streamline the documentation we provide to follow "our way".
Any arguments against html as our documentation format?
cheers,
Oliver
Other related posts:
