manwhich: Deriving MANPATH from PATH [PSARC/2007/688 FastTrack timeout 12/19/2007]

[Mike Gerdts]

On Dec 13, 2007 1:43 PM, Joseph Kowalski <jek3 at sun.com> wrote:
>
> Glad to see you are making an enhancement in this area.
>
> I have an observation which is only marginally related to the actual
> content of this proposal...
> >         - The parent directory of the PATH directory with /share/man
> >           appended.  For example, /usr/gnu/bin becomes
> >           /usr/gnu/share/man.
> >
> The semantic of "share", as in "/usr/share", is that files here are
> platform independent.
> This not only means "ISA", but it also can mean "endian-ness".  This
> directory was
> invented by Sun to allow these files to be shared by diskless clients of
> different flavors:
>
>     mount server:/.../hostname.root /
>     mount server:/.../$ISA/usr /usr
>     mount server:/.../usr/share /usr/share
>
> Yea, when it was invented, a couple of 10's of megabytes of rotating
> rust was
> significant.  I doubt anyone does this anymore, but its legacy.
>
> My point is that while /usr/share has a real use, all the other "share"
> directories are
> just noise (at best) and misleading (at worse).  Nobody adds them to the
> share
> command on a server.
>
> We shouldn't do anything which validates this practice, hence I think
> the above
> step should be deleted from your algorithm.
>
> I guess the rationale is that Linux (and the LSB/FSH) had no clue as to why
> Sun/Solaris (er, SunOS) had something called /usr/share and it seems
> they just
> propagated it with out understanding why.  (Actually, to be fair, the
> same can
> be said about many employees.) Hence, as Sun imports FOSS, it probably
> isn't worth the effort (or confusion) of refactoring these local
> directories.  We
> could just add a link "man -> ./share/man" as needed.

The /usr/man -> share/man link does exist today and is documented in
filesystem(5).  I'm not sure that I am ready to take on filesystem(5)
today.


> That's what I'd like.
>
> However, I'd accept wording on the man(1) (and related) pages that
> highlighted
> that the second set above is just a legacy/convenience thing.  We don't
> want to
> validate the practice of sprinkling "share" directories around.
>
> Also, along this line, shouldn't the algorithm reverse the priority of
> steps #2 and #3?

This working in filesystem(5) suggests it may be the right thing to
do.  Unfortunately, those that created /usr/gnu/{bin,share/man} didn't
take it into consideration:

     /usr/share/man

         Platform-independent sharable manual pages. An  approved
         installation  location for bundled Solaris software. The
         analogous location for add-on  system  software  or  for
         applications is /opt/packagename/man.

Given that there is now more focus on adding to /usr/bin rather than
adding more directories like /usr/sfw and /usr/gnu, there should be
relatively few *Solaris directories that subscribe to share/man.
Since third parties should be installing software to /opt/packagename
with /opt/packagename/man as the man directory, reversing the search
order to prefer man over share/man seems appropriate.

> Finally, for this proposal to be complete, I think you need to enumerate
> the cases
> handled by #1 (the explicit translation rules).  I doubt they are
> controversial, but
> they should be enumerated for completeness.

The mapping is...

/sbin			/usr/share/man,1m
/usr/sbin		/usr/share/man,1m
/usr/ucb		/usr/share/man,1b
/usr/bin		/usr/share/man,1,1m,1s,1t,1c,1f
/usr/xpg4/bin		/usr/share/man,1
/usr/xpg6/bin		/usr/share/man,1

-- 
Mike Gerdts
http://mgerdts.blogspot.com/