Re: Anybody working on removing sendmail from base?

[Chris Pressey <cpressey@xxxxxxxxxxxxxxx>]

On Wed, 1 Oct 2003 10:13:18 -0600
Mike Porter <mupi@xxxxxxxxx> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wednesday 01 October 2003 09:00 am, Chris Pressey wrote:
> > On Wed, 1 Oct 2003 02:02:06 -0600
> >
> 
> > I thought the point of hiding utilities was to eliminate conflicts:
> > if A wants X 1.0 and B wants X 1.1 then A sees X 1.0 and B sees X
> > 1.1 regardless of how much X 1.0 and X 1.1 overlap.
> >
> > Same principle applies when A is the OS, B is the user, X is a
> > compiler.
> 
> OK I see that point, however, there is no 'real' hiding, since user B
> is free to choose X1.0 or X1.1 at any time, under the variant symlinks
> theory, simply by changing an environment variable (COMPILER=).

OK - that might be as 'real' as the hiding gets, if it's implemented
only with variant symlinks.

The part I don't understand, actually, is how variant symlinks are
related to DragonFly's new VFS [can I call it DFVFS for the time being?]

Are varsyms a part of DFVFS, or are they seperate and alongside it?
If they are seperate - is it a duplication of functionality?

As I understand it (not terribly well :) a major part of DFVFS will be
cleaning up the existing VFS code - getting rid of the reentrancy
problems - so that it can support real unionfs-type mounts.  As I
understand *that*, it means you'll be able to explicitly 'layer' parts
of a filesystem together, to assemble whatever 'view' of it you like.

Taking that into account, it looks like varsyms and DFVFS+unionfs, are
two different ways of solving the same problem.  Are both needed?  Can
the work of varsyms be done with, say, DFVFS+viewfs, where viewfs is a
filesystem that somehow decides what the file system should 'look' like
to the user, based on many factors (explicit overlaying configuration
and environment variables being two important factors, but possibly only
scratching the surface?  For example, another factor might be what
groups the user belongs to, perhaps introducing some interesting
possibilities for 'realer' hiding.)

> What I am arguing against 
> is the idea that user B would not see X1.0 without explicitly
> installing it, even though it is already installed by your system. 

Well... I think the only thing I can think of here, is that with the new
package system, the definition of 'install' becomes more abstract than
we've probably come to expect.

Presumably 'install' is an operation provided by the package system. 
When you want new software, you tell the package system, "I want new
software!  Give me X 1.0!" or something, and it takes care of the rest.

In other words... the end product of installing X 1.0 *is* for B to be
able to see X 1.0, regardless of what that involves.  It may involve
downloading, untarring, possibly compiling, and making new executables
available - or, it may not, *if* those executables are already there,
but currently unavailable to B.  In which case it's a simple matter of
altering B's view (however that's implemented.)

At least, as I understand it.

-Chris