On Sep 20, 2009, at 07:11, Rainer Müller wrote:
On 2009-09-20 00:28 , Ryan Schmidt wrote:
If your MANPATH is empty (as I believe we recommend), then man will
automatically search for things in all the locations specified in
PATH
(that is, for every path in PATH, man will look in ../share/man for
manpages).
The installer still sets up a non-empty MANPATH. Using an empty
MANPATH
is only recommend on ProblemHotlist as it is the most easy fix, but
adds
additional time to search from bin for man or share/man.
The MacPorts installer package postflight script only modifies the
MANPATH if it is not empty. If it is empty, no modification is needed;
the manpages are found automatically by searching ../share/man
relative to each entry of PATH. Surely the amount of time the computer
needs to translate the strings in PATH isn't large?
When Leopard was released we discovered it now put things in MANPATH
by default, to enable path_helper to work. This was a bit annoying
because it disabled the automatic manpage finding, and it appears that
Apple learned in Snow Leopard, and MANPATH is no longer modified for
path_helper if it is empty (according to the manpage for path_helper).
Though it's sounding strange for libexec/gnu to be its own prefix.
apach2, for example, uses ${prefix}/apache2 as its prefix. Granted
that violates the mtree, which I originally objected to in this
thread. :/ Guess I don't really know where it should go.
We often talked about apache2 as a bad example of mtree violation
and we
agreed that it is bad and should be changed.
Yes, hence my hesitation.
But if I remember correctly
this is the default layout the build system produces.
It's what happens when you use --prefix=${prefix}/${name} anyway,
which is what the port does. Who knows what would happen if we left it
at the default --prefix=${prefix}.
We could even provide a small "gnuify" script in ${prefix}/bin which
would set up the appropriate PATH and MANPATH. For users it wouldn't
matter if the GNU binaries with original names are in ${prefix}/gnu or
${prefix}/libexec/gnu or whatever, they just call gnuify once (or
add it
to their profile).
We could provide such a script, but if we set MANPATH in it, it would
have the disadvantage of making MANPATH nonempty again and thus
disabling the automatic manpage finding feature which the user may
have been relying on for other manpages. The discussion was between
having a directory under ${prefix} which would behave like a prefix
for GNU software -- would contain bin and share directories -- or
making GNU subdirectories within both the ${prefix}/bin and ${prefix}/
share directories; the automatic manpage finding feature wouldn't be
able to find the manpages given that layout.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
