[539] in Release_7.7_team
Re: sun4m_54
daemon@ATHENA.MIT.EDU (Craig Fields)
Sun May 19 13:44:26 1996
Date: Sun, 19 May 96 13:44:20 -0400
From: Craig Fields <cfields@MIT.EDU>
To: danw@MIT.EDU
Cc: testers@MIT.EDU, release-team@MIT.EDU
So you would also want add to do this, I assume?
> It just seems really bogus to me that if a locker is set up with the
> old-style $bindir system (which you're not supposed to use any more)
> that it will work fine, but if it's set up with the new, recommended
> $ATHENA_SYS system, it loses.
The situation would be more or less reversed in the case of a new
release that couldn't run the binaries of the old one - you might get
ugly things happening using the old convention, while with the new one
you get no crufty binaries in your path.
Arguably, binaries should be recompiled under the new operating system
rather than relying on binary compatibility. So the fact that things
would continue to work when using the old system was broken, and
having things break as they do under the new system is the correct
behavior. War is peace. Slavery is freedom.
But I think we have never really addressed the issue of trying to
support binary compatibility in this way. Should athdir and add know
about what @sys values are compatible with what others, or should we
just have the locker maintainers deal? (And in this specific case, do
we know that all sun4m_53 binaries should run properly under
sun4m_54?)
Craig
