[OpenIndiana-discuss] Namespace management and symlinks in /usr

[James Carlson]

Reginald Beardsley wrote:
> I'm a geoscientist and have spent most of my career working for "big oil" as in majors and super majors.  Those certainly qualify as "large sites" and are a lot bigger than any academic institute I know of. So I'm acutely aware of the issues and what things work and what things don't.
> 
> A site administrator's job is to protect the user community from disruptive changes.  However, that does not entitle any site administrator to push bandaids onto the larger user community.  It is the profligate use of bandaids to which I'm objecting.

I think both of you are right (and wrong) in a way.

Intentionally introduced set of links that aid in compatibility and that
are put in place by the designer of the system (and that hopefully
disappear at some point in the future when no longer useful) == good.

Ad-hoc forest of links created by some administrator who isn't directly
involved with the fundamental system design and that likely persist way
past their "sell or use by" date == bad.

So, I suggest that someone who is interested in this sort of clean-up
effort should catalog the links that exist, exclude the ones that are
intentional and good, and provide a summary of links that are presumed
to be either obsolescent or just hazardous.

At least some of the things I see look good to me.  Having the p* tools
symlinked in /usr/proc/bin matches where they were originally, and any
script that invokes /usr/proc/bin/pkill (or similar) would be harmed by
removing these, with little obvious benefit in the clean-up.  And having
/usr/bin/g* symlinked to /usr/gnu/bin/* makes a lot of sense for
commonly used things, as the g-prefix is a pretty well-known
cross-platform allowance for GNU stuff, and having a separate unprefixed
/usr/gnu/bin directory means that those who want to live in an
unprefixed world can just prepend that to their PATHs.  Best of both
with little pain.

I suspect that final set of bad actors is really quite small, but
perhaps you or one of the other contributors has something else in mind.

-- 
James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>