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

[David Halko]

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


(I can't believe I am about to say this...) I would suggest... symlinks for
compatibility could be at the distro level.

When I say that this should be distro level, this should not absolve
Illumos from responsibility in moving things around. If Illumos pulls
things out of their core, they should document it, indicate where it is at,
so a distro can easily pick it up. If Illumos moves things around, then a
distro can easily add symlinks to make it happen.

Honestly, this should be an automatic process... it should not be manual.
Every binary, ".so", etc. with compiler vendor/version should be referenced
in a federated on-line read-only "database" of some kind. A distro could
help to figure out what is needed, update their tree in the database,
Illumos should keep track of where their binaries are, in comparison to a
(nonchanging) base distribution like the final OpenSolaris release.

>From there, people could build maps to all OpenSolaris releases,
other Solaris 10 releases, Solaris 9 releases, newer Solaris 11 releases. A
user could request "Solaris 10 Update 10 Compatibility Kit" and a tar/cpio
of extra directories & symlinks could be created from the federated
directory.

If there are files in /bin, /lib, /etc, these should be for "core" Illumos
binaries which have no upstream... an update from an external source should
never break the core OS (kernel, svcs, zfs, ufs, etc.)

If something has an upstream (GNU software, ksh93, etc.) - perhaps those
files should be off the /usr namespace.

If something is unmaintained and pulled from old Sun code, perhaps those
files should be in a /usr/sunw, /lib/sunw, etc. namespace.

If something is pulled from older SVR4 or older BSD, perhaps those files
should be elsewhere in /usr/s5 and /usr/ucb namespaces, respectively.

If something is absolutely huge, like a third party package repository,
such as  Sunfreeware, UnixPackages, OpenCSW, etc. - they could packages &
prefix in /opt, /var, etc. namespaces, as they do today.

I think that X11 with children like JDS, CDE, Motif, OpenWindows get
complicated, since they have their own frameworks. Since people often like
to run multiple frameworks on a platform, or multiple X11 releases, using
namespaces like X11R6.1, X11R7.0 has a place, with possibly a symlink
pointing from /usr/X11. If they are supported by the Illumos core team,
perhaps it is like /usr/dt /usr/openwin, like it was before under Sun. If
they will no longer be supported by the core team, perhaps a final
compilation & move to /opt?

Doing this, a minimial Illumos distro, which could be embedded, could be
built from /bin, /lib, /var, /etc and stick it on a Linksys Router; add
/usr tree and stick it on USB stick for portable OS; add /opt for
desktops/servers with external package providers.

Just some thoughts... take some of it, take all of it, take none of it at
all...
Thanks - Dave
http://svr4.blogspot.com/