[5247] in SIPB bug reports
sipb locker reorg
daemon@ATHENA.MIT.EDU (yandros@MIT.EDU)
Fri Mar 24 02:00:35 1995
From: yandros@MIT.EDU
Date: Fri, 24 Mar 1995 06:56:36 GMT
To: bug-sipb@MIT.EDU
Ok, some people have been asking, so I'll announce now that the SIPB
locker reorg will take place this weekend, after midterm week and well
into minimal-damage time. (imagine Mosaic breaking in the middle of
6.033? :-)
The major question I still have concerns the `lib or share' idea. In
particular, whether to have:
/mit/sipb/
lib/exec <- scripts, etc.
lib/foo <- library info for `foo'
/mit/sipb
share/exec <- scripts
share/lib/foo <- library info for `foo'
there are obvious places where `share' and `lib' as names could be
interchanged.
Another issue is whether to make /mit/sipb/{bin,lib,etc} symlinks to
the relevant one of /mit/sipb/arch/@sys/{bin,lib,etc}. I've heard
arguments for (yoav) and against (sal). Any suggestion should keep in
mind the folling constraints:
o /mit/sipb/lib/elisp is a widely-used and `exported' interface.
o lots of programs currently reference files in /mit/sipb/lib. These
would presumably all have to be recompiled or `interesting' symlink
forrests would need to be developed.
Yes, the two issues are related.
One more note for the people who seem to feel that we should just `let
athena decide'; they don't plan to. I talked to Craig, and they don't
have anything specified, nor do they seem to have any plans to do so
in the near future. It seems not unlikely that a well thought out
setup in the sipb locker would become a standard model..
chad
