Remove +with_default_names and use a specific path for unprefixed binaries

[Mark A. Miller]

On Sat, Sep 19, 2009 at 5:28 PM, Ryan Schmidt <ryandesign at macports.org>wrote:

>
> On Sep 19, 2009, at 15:06, Mark A. Miller wrote:
>
>  On Sat, Sep 19, 2009 at 1:07 PM, Ryan Schmidt wrote:
>>
>>  On Sep 18, 2009, at 22:20, Mark A. Miller wrote:
>>>
>>>  So, ${prefix}/libexec/gnubin seems to work, and put symlinks there for
>>>> the GNU binaries by default, and get rid of this variant?
>>>>
>>>
>>>
>>> I would say so... I see Marcus already committed an update to do this to
>>> gnutar. But now I see the with_default_names variant did more than just
>>> install unprefixed binaries. It also installed unprefixed manpages and
>>> whatever was in share. For gnutar, there appears to be nothing in libexec
>>> and only info pages in share but maybe other ports that have this variant
>>> have things in libexec, and also manpages. Do we need "gnushare" and
>>> "gnulibexec" dirs too? Or do we need to put bin, share and libexec
>>> directories into ${prefix}/libexec/gnu maybe? Presumably if you have your
>>> PATH set up so that, say, GNU sed is first, then it would be confusing to
>>> say "man sed" and get the system's BSD sed manual...
>>>
>>
>> ${prefix}/libexec/gnu sounds like a good idea, although that would involve
>> adding an additional path to $MANPATH.
>>
>
> 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).
>

It's not empty, as seen by my .profile modified by MacPorts install:

# MacPorts Installer addition on 2009-06-11_at_17:44:56: adding an
appropriate MANPATH variable for use with MacPorts.
export MANPATH=/opt/local/share/man:$MANPATH
# Finished adapting your MANPATH environment variable for use with MacPorts.

But making it empty still results it the behavior you describe,
so...redundancy yay!


> 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.
>

Is there really anything bad other than "strange"? Sure it's perhaps
strange, but for the people who don't need this, it doesn't ever bother
them, and the people who do, it is a nice, cool little addition.
${prefix}/var/gnu? ${prefix}/share/gnu?

-- 
Mark A. Miller
mark at mirell.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090919/39bdd21d/attachment-0001.html>