Remove +with_default_names and use a specific path for unprefixed binaries

[Ryan Schmidt]

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.