Another crazy idea. "symlink paths" "virtual directories"

[Garance A Drosihn <drosih@xxxxxxx>]

At 3:26 PM -0400 10/9/03, Paul Jarc wrote:
> Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx> wrote:
>  > There is the problem of either having to modify a lot of
>  > application to look in various directories (e.g. Gnome
>  > and KDE the worst examples),
>
> This is usually not too hard.

It can get tricky at times, depending on your constraints.

>  > make excessive use of variant symlinks
>
> Well, that depends on your definition of "excessive".  Given
> the benefits, I certainly don't mind the large number of
> symlinks at all.

Here at RPI we had (and still have) a strategy which sounds
something like slashpackage.  We have two tactics we use.
For simple programs, we use a symlink from /usr/local/bin
to the file.  For a packaged collection of programs, we
put them all in a separate directory, and then have ways
to modify the PATH variable for users so they will get that
package.  The details are probably not interesting, but I
am used to handling packages via that method.

Given that background, the comment about "excessive" symlinks
made me think of another idea which might be interesting.  I'm
thinking it could be called "symlink paths" or maybe "virtual
directories", and it would be a feature supplied by the OS or
filesystem layer.

The idea is that you could create a "directory", but that fake
directory would be nothing more than a symlink which was a list
of pathnames to other directories.  Programs which looked at
that directory would see it as a single, read-only, virtual
directory.  In that virtual directory would be a list of files,
where that list would be based on the files one would find by
combining the directories given in the "symlink path".  If
multiple directories had the same filename, then the file seen
in this virtual directory would be determined by the order that
the directories were listed in the "symlink path".

So, you could install
perl5   into /usr/local/pkg/perl5/{bin,lib,etc}
perl6   into /usr/local/pkg/perl6/{bin,lib,etc}
ruby1.6 into /usr/local/pkg/ruby1p6/{bin,lib,etc}
ruby1.8 into /usr/local/pkg/ruby1p8/{bin,lib,etc}

and then have a mkdir-like command to create the initial
virtual directory:

mkvdir /usr/local/vbin \
           /usr/local/pkg/perl5/bin \
           /usr/local/pkg/ruby1p6/bin

All the programs installed in (say) /usr/local/pkg/perl5
would use hard-coded references to that path name.  People
wanting the "standard programs" would just add the one
directory to their PATH variable.  If they wanted to get
ruby 1.8 instead of 1.6, they would add the real directory
for that specific version to their PATH, ahead of the
reference to /usr/local/vbin.

At the moment I think this (if fleshed out a bit more) could
be interesting.  On the other hand, I've been putting in some
long days this week, so maybe I'm just hallucinating.

I imagine this boils down to a slightly different way to
approach some of the features that Matt has been thinking
of.  It's kind of like union filesystem-mounts, except
that I think it's clearer what is going on, and thus might
be easier to get it to "work right".

--
Garance Alistair Drosehn            =   gad@xxxxxxxxxxxxxxxxxxxx
Senior Systems Programmer           or  gad@xxxxxxxxxxx
Rensselaer Polytechnic Institute    or  drosih@xxxxxxx