[3556] in SIPB bug reports
missing /usr/sipb link
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Tue Mar 9 14:46:44 1993
Date: Tue, 9 Mar 93 14:47:07 -0500
From: "Jonathan I. Kamens" <jik@GZA.COM>
To: srz@Athena.MIT.EDU
Cc: aix32@Athena.MIT.EDU, bug-sipb@Athena.MIT.EDU, sipb-staff@Athena.MIT.EDU
In-Reply-To: srz@Athena.MIT.EDU's message of Tue, 9 Mar 93 14:38:42 -0500 <9303091938.AA08832@carbonara>
From: srz@Athena.MIT.EDU
Date: Tue, 9 Mar 93 14:38:42 -0500
There is an order of effort difference here: the level of effort for
Athena to create and maintain the link is orders of magnitude less
than the effort and headaches for SIPB to "fix" all the programs.
And, as was pointed out last time this came up, for the layered
platforms where the requirements are that the only modification to the
vendor filesystem are "/usr/athena", there can't *be* a "/usr/sipb"
link.
We asked Athena about this the last time it came up. And they said
that there was a distinct possibility that /usr/sipb would go away in
a future Athena release. Whether the lack of /usr/sipb in the AIX 3.2
release is intentional or not, it's an example of how true this is.
If our programs rely on /mit/sipb, this isn't a problem.
Why
create busy work for people? Killing flies with shotguns is not very
efficient.
/usr/sipb is an artifact. As I mentioned the last time this came up,
I've been trying to install all new applications with just /mit/sipb
paths. Besides that, I wouldn't say that there are any "orders of
magnitude" at all involved in fixing programs not to use /usr/sipb.
I'll do it, if no one else wants to.
jik
