Re: Anybody working on removing sendmail from base?

[Mike Porter <mupi@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 01 October 2003 11:10 am, Chris Pressey wrote:
> On Wed, 1 Oct 2003 10:13:18 -0600
>
> Mike Porter <mupi@xxxxxxxxx> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >

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

My main point is that I don't see a point in implementing any more of a 
"hiding" than that.  If we are going to put together a system where the 
package subsytem can pull in any version needed of gcc or perl --and 
installing a new version of gcc or perl won't interfere with the system's 
versions -- then we have accomplished the goal of eliminating a porter's 
dependency on the system's compiler.  There is no need to hide anything.  
*some* ports will work fine with the sytem's comiler, and for those, there is 
no reason to do anything else.  Other ports, the software won't work with 
"older" compilers (and presumably, eventually at least, neither will dfBSD 
itself, but of course, that is a different discussion), and so the porter can 
specify a 'minimum' version to use.  Perhaps a 'range' would prove more 
useful (as in, any gcc betwen 3.0 and 3.3 is known to work; you could define 
minversion and maxversion in the port.  If maxversion is undefined, use the 
latest version available, and when somone discovers a version that breaks it, 
the port maintainer can add a maxversion.  We might want a little bit of 
additional logic to stipulate, for example, Intel compiler versions that can 
be considered equivalent to gcc versions, for those who insist on using other 
compilers....

> 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.)
>
I think this is sort of true, but VFS 1) will be more work to get into the 
system, 2)while being more robust, may also incur a greater performance hit 
(on the other hand, it may prove the opposite is true) 3) it is going to be a 
lot less flexible than varsyms, since varsyms will be able to be changed by 
changing an environment variable.  This might also work for changing VFS, but 
I suspect that suddenly dropping out/changing the entire filesystem might 
confuse a lot of programs.  (in other words, would changing an enviroment 
variable cuase the entire VFS filesystem to be rebuilt for the user?  I don't 
know, but it sounds like it could)  Maintaining the filesystem integrity 
might demand that such changes be limited to .profile or .login, requiring a 
logout/login to be effective.  varsyms will only affect a small part of the 
filesystem, typically a part not currently in use by the process, so this 
should be minimized.

>
> 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.
>
I can see that.

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

As I said before, I don't see the point/need to make a program 'unavailable' 
to a user (in any sense except that typing, for example, 'gcc --version' will 
result in a different value).  To me, the idea of a program being unavailable 
means that no matter what I do as the user, I will never see/know that the 
program is installed.  This to me is overkill.  If I was looking through 
/usr/local/, I would be able to see whatever is installed 
/usr/local/gcc-2.95.4 and /usr/local/gcc-3.4.n, and know that by setting 
$GCC_VERSION I could type, e.g., 'set GCC_VERSION=2.95.4; gcc --version' and 
get "2.95.4" then type 'set GCC_VERSION=3.4.n; gcc --version' and get "3.4.n"

anyway, time to go work at my paying job...

mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE/e2ejY30jZzkECLcRAhFaAJ9OkDnqxWejAcej13BHRWEqIPIH6QCcCeB9
uzqNY0wyP4l4Ww3K2CGfriA=
=KXQP
-----END PGP SIGNATURE-----