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

[Reginald Beardsley]

--- On Wed, 10/17/12, James Carlson <carlsonj at workingcode.com> wrote:

> From: James Carlson <carlsonj at workingcode.com>
> Subject: Re: [OpenIndiana-discuss] Namespace management and symlinks in /usr
> To: "Discussion list for OpenIndiana" <openindiana-discuss at openindiana.org>
> Date: Wednesday, October 17, 2012, 2:45 PM
> 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.
> 

So *when* do they disappear?  That's the question I'm raising.  What are criteria for acceptable links?  Why are user & site level customizations cluttering a general distribution image?

I'm concerned about the proliferation. 15715 symlinks is a lot of links. I don't see any sign of discipline.  Do we really need a symlink in /usr/sbin to everything in /sbin? Setting PATH properly is much cleaner.

We have similar silliness w/ /usr/X11 being a tree of links pointing to /usr.  Again, setting the default PATH properly in the system files is much cleaner.

I raised this because

find -L /usr -type l -print

produces a list w/ 10 cycles and 132 dangling links.  That is broken by any standard. When I find loops and broken links in the directory tree I start getting worried.  I worked in two environments that were brought to their knees by that. And in both cases it all started out as "a good idea".

I'm all in favor of disciplined use of symlinks. I use a large table of links to select the active version of software I compile from source.

find /app/{bin,lib,include,man,share} -type l -print | wc 

reports 15464 links.  But they're not links to links unless the package itself contains links for things like library aliases and all the links point into /app/pkgs. It's carefully designed so that I can safely install things w/o undetected name space collisions among third party packages.  It also lets me toggle between versions quickly.  But the primary motivation was making sure that "make install" didn't cause any damage.

Reg