[5184] in SIPB bug reports
Re: Created sipbsrc.sgi_52.nb
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Mar 1 23:55:02 1995
To: yandros@MIT.EDU
Cc: bug-sipb@MIT.EDU
In-Reply-To: Your message of "Thu, 02 Mar 1995 04:29:01 GMT."
<199503020429.EAA07887@infocalypse.MIT.EDU>
Date: Wed, 01 Mar 1995 23:54:56 EST
From: Greg Hudson <ghudson@MIT.EDU>
> I renamed the volume and mountpoint to sipbsrc.sgi.nb, to match the
> rest of the volumes.
As requested, here is an organized argument for:
Why mountpoints and names for architecture-specific volumes
should be OS-version-dependent for architecture-specific
-----------------------------------------------------------
1. The new Athena binary placement convention puts OS versions in the
path users use to reference binary placements. Thus, using
OS-version-independent volume names requires unnecessary symlinks
under the binary placement convention.
2. Owing to (1), the "logical architecture names" returned by machtype
have been stripped of most of their meaning (since they're no longer
used by "add" on new platforms) and are unlikely to obey any
particular discipline relating to binary compatibility.
3. OS version dependence does not tie volumes or mountpoints to any
particular version number; it simply indicates a promise that the
contents of the mountpoint will run on that version of the operating
system, and by extension any other version which is binary-compatible
with that version.
4. Dealing with one-way compatibility (e.g. Irix 5.x can run Irix 4.x
binaries, but not the other way around) is a Hard Problem (tm) which
is made harder, not easier, by OS-version-independent naming. With
version dependence, you can choose any of the following:
* You can make a new volume for the new OS version, and copy
or symlink binaries from the old OS version's volume.
* You can rename the mountpoint and volume name, thus revoking
the promise that the binaries will work on the old OS
version, if you don't want to support the old version any
more. (You can leave a symlink for the old version with the
proviso that programs may start to break for the old
operating system as programs are rebuilt.)
* You can symlink the new version to the old version, so that
you still have the promise that the programs will work on
the old version, and mandate that programs are rebuilt
using the old version.
With OS-version-independent naming, the promises made are less clear,
and it is more difficult to tell whether people are doing the correct
thing when they, for instance, build a Solaris binary and put it in
"sun4bin" while SunOS machines are still using sun4bin.
----------
Here are the claims and pieces of evidence that I could find in Chad's
zephyrgrams:
* We've had programs in a volume mounted in pmax_ul3 which
didn't run on Ultrix 3.
* We've had programs in a volume mounted in rs_aix31 which
didn't run on AIX 3.1.
* Version-dependent naming creates more work for maintainers
by requiring them to clean things up when they get too
crufty.
* Version-dependent naming leads to "symlink farms and useless
cruft".
The first two pieces of evidence are clearly examples of maintainer
errors, and version-dependent naming allows us to easily identify
these maintainer errors. It would be much harder to identify such
behavior as errors if the volumes were simply named by "decmips" or
"rsaix" without regards to what versions of the OSs we claim to
support.
The third claim is, I think, a dodge. If a volume and mountpoint is
named with sgi_52 and Irix 5.3 comes out, it is perfectly reasonable
for the volume to remain with the name sgi_52 (and sgi_53 to be a
symlink to sgi_52) as long as the two versions of Irix are mutually
binary compatible, by my argument (3). On the other hand, if Irix 6
comes out and is only compatible one way, maintainer effort is
required no matter what the naming scheme used.
The fourth claim is simply false, as far as I can tell. Symlink farms
need only be created if they are deemed necessary to deal with one-way
compatibility, and "useless cruft" is too vague for me to respond to.
Version-independent naming isn't going to help us avoid these things.
