Re: union mounts

On Sat, Nov 07, 1998 at 12:18:24PM -0800, Eric Dorman wrote:
> > I find this an interesting concept considering that modern shells walk
> > your 'path' and bring everything into an in-memory hash table
> > anyhow. What's the big win of doing a union bin?
>
> Coz then you don't have to complicate the shell with PATH and
> caching nonsense. Plus one doesn't have to do screwy things with
> mounts if you have clients with different architectures.

1) All modern shells (bash,tcsh,zsh) do this regardless of whether you
use union mounts or not. I suppose the union mount lib could keep hash
tables itself.

2) To me it's not so important whether you use union mounts or my
scheme for adding the package to your environment. The important part
is that you specify the package with a logical name (like
netscape-4.03) not a physical name (like
/usr/local/enca/netscape-4.03). In the union mout scheme, if you end
up with some file doing something like "mount
//dev/disk/01:usr/local/apps/netscape-4.03 /usr/local" then you've
gone the wrong direction. _that_ kind of thing is what makes
environment setup screwy for different architectures.

For reference, the UnixTools system I setup automatically setup the
correct binaries based on the platform you were on. The user would
merely specify "logical" application names.

3) what do you do with union mounts when you have naming collisions?

> [xxx 'encapsulation']
> > This allows me to have lots of versions of the same things installed,
> > and allows me to be more aware of command line naming conflicts.
>
> This is an advantage? Seems the road to madness, with the possibilities
> of different header, log or data file formats with misc. versions floating
> around. Plus it gets icky quickly if multiple architectures must be
> supported.

The road to madness is forcing everyone to upgrade to a new version at
the same time.

I came up with the UnixTools structure while doing VHDL design at S3
(a PC graphics chip maker). Hardware design projects choose a tool
version, and need that tool version to stay the same for the duration
of the project. Another project (going on at the same time) may choose
a different tool version. Changing tools mid-stream is _not_
possible. Keeping the network shares separate is also not possible,
because people work on mulitple projects. In addition, you want to be
able to pull out a design from the source control tool a year later
and actually have it build. That means that old version of software
need to persist at all times.

While this certainly is a particular installation with particular
needs, I find the structure make much more sense even for my own
personal use. I don't like upgrading before I've tested the new
version. If you have to delete the old version to install a new one,
then you are putting yourself at risk of not being able to get back to
where you were. What if the new version dosn't function correctly?
What if you have some trouble re-installing the old one?

Personally, I like to test the seaworthyness of my next ship before I
sink the old one. Others clearly like to sail the ocean in a more
risky manner.

FWIW, UnixTools beautifully handles multiple architecutres:

netscape-4.03.encap/sun-solaris/bin/*
                    i386-linux/bin/*

Because the environment setup is based on logical names, the UnixTools
environment setup automatically chooses the correct binaries to put
into your environment. It also does neat things like automatic
notifications of environment changes (i.e. if a user is asking for the
"current-tools" toolset, it'll tell them when that environment
changes).

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske_at_chat.net