[2694] in testers
No subject found in mail header
daemon@ATHENA.MIT.EDU (Ezra Peisach)
Wed Aug 10 10:30:38 1994
To: Jake Wetzel <jawetzel@MIT.EDU>
Cc: cfields@MIT.EDU, marc@MIT.EDU, yandros@MIT.EDU, testers@MIT.EDU
In-Reply-To: Your message of "Wed, 10 Aug 1994 06:54:50 EDT."
<9408101054.AA17424@m37-332-5.MIT.EDU>
Date: Wed, 10 Aug 1994 10:30:07 EDT
From: Ezra Peisach <epeisach@MIT.EDU>
First a bit of history.... The use of common mount points was required
when there was felt the need for required compatibility with previous
releases. Taking x11 for examples, the system packs used to have the x
libraries and include files. We then were switching to x11r4 (while
keeping x10 about) and to make it so that the developers did not have to
change their makefiles to -I/mit/x11r4/include
-L/mit/x11r4/`machtype`lib (remember we are taking NFS here - no @sys),
the overlaying of x11r3, r4, r5, .... with magic symlinks from the pack
were started.
In some cases, there was not really as much of an option. Some third
party software, like rs1 required that /usr/lib/rs1 be the path used -
no ifs or buts about it. Again, overloading of mount points were
required. Scribe was another case with it's license file.
So, now people are starting to complain about the overloading.... I see
several solutions:
a) Remove all symlinks on the system packs like /usr/athena/include/X11
and /usr/lib/libX* and force people to use lockers for compiling - it
worked for NAG. Of course the xmkmf generated files would need to know
about this..... The lockers should mount on /mit/x11r5 /mit/x11r6...
b) cleanup could do a detach -a (whatever), if and only if no one else
is logged into the machine.... Assuming that the machine is not hacked
all should be well.... But what about private machines, like in the sipb
office and everywhere else - you can't detach things underneath a user
who may be relying on them...
c) Have another name for x11r5, x11r6, etc.... If you attach x11, make
/mit/x11 be whatever you consider current (r4 or r5). attach x11r4
should attach on /mit/x11r4, etc. This way a developer can attach the
right one and have a mount point which is guaranteed to be what he/she
wants. (I don't know how you would configure xmkmf to DTRT).
Personally, I like (c). It would require prior notification of all
parties, but it would remove confusion in the future... Maybe even
another name for a real mount point generation..... Then if you run the
xmkmf in that locker it should be configured to use it....
Ezra
