[2757] in Athena Bugs

home help back first fref pref prev next nref lref last post

Backward compatibility of new dot files

daemon@ATHENA.MIT.EDU (epeisach@ATHENA.MIT.EDU)
Thu Aug 10 11:39:38 1989

From: <epeisach@ATHENA.MIT.EDU>
Date: Thu, 10 Aug 89 11:39:08 EDT
To: bugs@ATHENA.MIT.EDU, testers@ATHENA.MIT.EDU
Cc: jis@ATHENA.MIT.EDU

I logged into a 6.2 machine today and got the following message:

                echo "If this is a workstation in a public cluster, you should"
                echo "be getting the 6.3 upgrade within a few days."
                echo "If this is a private workstation, please contact the"
                echo "Athena Hotline at x3-1410 (by email: hotline@ATHENA),"
                echo "in order to arrange to have your workstation ungraded."

This implies that the new dot files cannot go into place until public
machines have been updated to 6.3B as the message would be meaningless
otherwise.  

This will mean that we must not start changing dot files until 6.3B
starts rolling out into the field. I'll later have to check old dot
files with 6.3B packs, but a cursory look appears to indicate that
things might fail as the stty dec is handled in older .login files or
the more recent /usr/athena/lib/init/login_init which will not be
sourced by this setup. 


Therefore, we have a problem. We cannot deploy new dot files until 6.3B
has some semblence of hitting the field, and we cannot put the new packs
out until dot files have changed. We could try for doing this
simultaneously, but I think we might lose. I believe we should rethink
this problem and possibly change our fallback files in
/usr/athena/lib/init to handle the stty dec there as an insurance
policy when source from .cshrc. This is not necessarily clean, but will
probably work. (At least for the new .login's that were given out last
year).

	Ezra




home help back first fref pref prev next nref lref last post