manpath change for ports ?

[Tijl Coosemans]

On Fri, 10 Mar 2017 08:38:30 -0800 Steve Kargl <sgk at troutmask.apl.washington.edu> wrote:
> On Fri, Mar 10, 2017 at 05:03:08PM +0100, Tijl Coosemans wrote:
>> On Fri, 10 Mar 2017 10:50:39 +0100 Dag-Erling Smørgrav <des at des.no> wrote:  
>>> John Baldwin <jhb at freebsd.org> writes:  
>>>> I wouldn't even mind if we had both /usr/local/man and /usr/local/share/man
>>>> so long as our default MANPATH included both if that means applying fewer
>>>> patches to ports.    
>>> 
>>> The default MANPATH is constructed dynamically from PATH:
>>> 
>>>      1.   From each component of the user's PATH for the first of:
>>>           -   pathname/man
>>>           -   pathname/MAN
>>>           -   If pathname ends with /bin: pathname/../man
>>>           Note: Special logic exists to make /bin and /usr/bin look in
>>>           /usr/share/man for manual files.
>>> 
>>> If we change this to:
>>> 
>>>      1.   From each component of the user's PATH for the first of:
>>>           -   pathname/man
>>>           -   pathname/MAN
>>>           -   If pathname ends with /bin or /sbin: pathname/../man and
>>>               pathname/../share/man
>>> 
>>> we wouldn't need any "special logic", but I really don't like the idea
>>> of having different ports installing man pages in different locations.  
>> 
>> I grepped the ports tree and found nearly 5700 ports.  That's a lot to
>> change all at once but it may be doable.  It depends on how much fallout
>> there is in the exp-run.  
> 
> ln -s /usr/local/share/man /usr/local/man
> 
> should cause the manpages to land where you want.  Then port
> maintainers can sweep ports/ to allow for the removal of symlink. 

Yeah, I had to deal with installing through symlinks in the Linux ports
because bin, lib and sbin have become symlinks there now.  There are
complications with that.  FreeBSD releases have a bug in libarchive that
causes problems when extracting hardlinks through symlinks.  Recent
versions of pkg have workarounds for that but not everybody runs it yet.
Before you can create the symlink you have to move the existing
directory, but what if the new directory already exists?  Will you
overwrite files?  Commands like pkg-which and pkg-delete only work
through the symlink because the new paths are not in the pkg database.
Packages that don't know about the symlink may try to create it as a
directory or remove it as a directory on uninstall.  I ended up avoiding
it at all costs in the Linux ports by moving files around in the staging
area if necessary.