Alexandre Oliva wrote:
>
> > which leads me to the question where the /doc should go under,
>
> Perhaps instead of --docdir we should have --doc-prefix, that defaults
> to --prefix? Then man, info, html, etc would all be in /usr/local by
> default, but this could be easily overridden using --doc-prefix.
>
> Another idea is to have mandir and infodir default to
> prefix/{man,info} if --docdir is not specified (in which case it would
> default to ${datadir}/doc, and to $doc_prefix/{man,info} otherwise
> (not overriding --mandir or --infodir, of course). Yes, I agree this
> is messier to implement and describe, but it seems to make installers'
> and distributors' lives simpler.
>
It took me a while to get the idea, Alexandre, let me summarize it
as far as I understand the bits:
fhs suggests, that (man|info) is placed directly and in parallel
to the (bin|lib) directory in the case of /opt. and /usr/local,
while at the same time these doc-directories are placed inside
of /usr/share instead of /usr just for the software that is going
into /usr/bin. In other places it mentions that data-directories
(like termcap) should be moved into the /usr/share subtree.
What I get is that all docs for software in the two os-vendor
prefixes / and /usr should be assembled into /usr/share, while
at the same time their $prefix-based directories are using them
directly attached. On another account we see text looking into
package-wise installations (/opt/<package>) which propose to
set the (bin|lib|man|info) directories directly thereunder.
Basically I see that the current assumptions for $infodir and
$mandir to be based on $prefix is right as we deal with
self-installed "add-on" software. However os-vendors will
try to put the docs out of $prefix into the share-subfolder,
and incidentally $datadir has a default of $prefix/share.
But it is wrong to use just that as the (share)-subfolder
is supposed to contain other data-directories like
(desktop|pixmap). Currently the os-vendor has to know which
doc-directores are valid *and* placed in $prefix, and adapt
the configure-call accordingly. New doc-directories would
not be affected as their maintainers would easily be tempted
to use $datadir as its base.
However the idea of a $docprefix does fit in nicely herein -
it will make it easy for a dist-maker to switch all docs over
into a share-directory as it is suggested by fhs, and if
anyone cares to, all these docs can even be put into a dir that
is somewhere reachable from a httpd. The default however should
be $docprefix=$prefix just like $execprefix=$prefix.
Anyone who starts to invent a doclike subdir will then be
tempted to let it be based on $docprefix. Good idea? It
could end up to populate the $prefix-directory, nothing that
is felt a nice move in the unix-world. Yes, as it is a
"prefix" no one would try to put their docs directly in
there, just a subdir, and doc/$PACKAGE looks good as a
gathering place for all kindes of docs of the package. And
if some new software goes to autoindex like we have with
(info|dir), users will adapt to use its path which will
again be based on $docprefix I guess. (footnote: just came
across a $docdatadir idea for docs that default into share)
Anyway, it is a long way to adapt autoconf|automake packages
to start using a $docprefix if we care to invent one - and
at the moment it would not hurt much as $docprefix defaults
to $prefix. One can even write an easy macro that will add
a (share) if $prefix=/usr and that will affect all the docs
to be moved. It does actually sound easier to have just one
switch to move docs instead of the current mess with using
options for (man|info), may be we can even drop their seperate
--(man|info)dir global-options somewhen in the future, also
thinking of the fact these multi-decade help-browsers might
be dusted away at some point.
So, I raise may hand to make the shift and introduce a
$docprefix, but I know it is not just my decision - most
prominently the gcs-guys (gnu coding standards) may want
to nod at it too, changing some docs for debian subsequently,
and following it's changing terminology in fhs-discussions.
No need to feel wimpy about, don't we ;-)
have lots of fun,
-- guido http://guidod.4t.com
31:GCS/E/S/P C++$++++ ULHS L++w- N++@ d(+-) s+a- y++ 5++X-
