[46] in DCNS Development
Re: Filesystem Reorganization for release 7.3
daemon@ATHENA.MIT.EDU (Ezra Peisach)
Wed Jul 3 08:54:24 1991
From: Ezra Peisach <epeisach@patriot.MIT.EDU>
To: Marc Horowitz <marc@MIT.EDU>
Cc: Mark Rosenstein <mar@MIT.EDU>, developers@MIT.EDU, release-73@MIT.EDU,
In-Reply-To: Your message of Wed, 03 Jul 91 01:16:29 -0400.
Date: Wed, 03 Jul 91 08:52:53 EDT
The issue is how to interact appropraitly with vendors who
supply their own version of X which is out of date. Joe Faculty member
has just bought a DECstation with all the subsets preloaded by DEC on it.
He wants to use Athena. We can no longer make the assumption that we
can take over his whole machine. Should we tell him that he has to unload
those subsets which conflicts with Athena (including X, Kerberos of so on)
and possibly not be able to do his development work because of changes
in libraries or binaries or should he be able to do both? We can no longer
build the X servers on the DECstations unless we want to lose the Display
Postscript abilities, which I consider too valuable. What we need is
a method which allows both systems to interoperate cleanly.
In regard to dot files, et. al., we will maintain certain
compatibility links where hard coded paths were given in the past. I have
already looked over the stock Answer tree and /usr/bin/X11 is not referenced
at all. "xmkmf" will do the right thing as it is a shell script. Users
who have customized their environment, bypassing the dot file scheme
which has been in use for over a year, will have to fix their environments.
Remember that such changes were made by users. $athena_path will be
modified to DTRT. We cannot help users who decide that "they know best".
Personally, I would like to see X11 remain in /usr/bin/X11, but I recognize
that unless such a migration is made, more inconsistancies will exist later.
between platforms which would be worse.
Ezra
