A file can move from one sharability level to another even when the list of levels doesn't change. If the change in sharability means a change in name, access to the file breaks. See below for two examples.
Sun eventually figured out its mistake. When it introduced another level of sharability, creating kernel-specific files, it set up symbolic links such as /usr/sbin/adb -> /usr/kvm/adb, so nothing broke.
It is wrong for sharability to determine the name by which a file is accessed. Sharability is not constant. Names must be constant.
How does /package support sharing? Answer: On systems that share files, the package manager can automatically set up appropriate symlinks, using some system-specific configuration and a small amount of sharing information included in the package:
/package/admin/daemontools-0.76/src
-> /shared/dist/admin/daemontools-0.76/src
/package/admin/daemontools-0.76/package
-> /shared/dist/admin/daemontools-0.76/package
/package/admin/daemontools-0.76/compile
-> /shared/syst/openbsd-i386/admin/daemontools-0.76/compile
/package/admin/daemontools-0.76/command
-> /shared/syst/openbsd-i386/admin/daemontools-0.76/command
But the only program that cares about this is the package manager.
The files are accessed without regard to sharability.
On systems that don't share files, there's no reason to bother with /shared. Keep it simple, stupid.
If you're building a package, you can easily support file sharing by creating a file package/sharing that says which directories are at which sharability levels. For example, here's /package/admin/daemontools-0.76/package/sharing:
command:syst
compile:syst
package:dist
src:dist
Here are the currently defined sharability levels:
Consider the ppplogin shell script Consider the perl executable
often used in /etc/passwd. often used in #! lines.
Shell scripts, just like Emacs Executables, just like libraries,
scripts, are at the /usr/share are at the /usr sharability level:
sharability level: read-only and read-only and
architecture-independent. architecture-dependent.
But what happens if ppplogin is But what happens if perl is
changed from a shell script to a recompiled separately for each CPU?
compiled program? Suddenly it's Suddenly it's CPU-dependent. It is
architecture-dependent. It is now now at a CPU-specific sharability
at the /usr sharability level. level, less sharable than /usr.
If you foolishly insist that this If you foolishly insist that this
change in sharability level be change in sharability level be
accompanied by a change in the accompanied by a change in the
name used to access the file, name used to access the file,
then the use of ppplogin in then the use of perl in
/etc/passwd will _break_. #! lines will _break_.
The program simply won't run. The program simply won't run.
How do we fix this? Do we scream How do we fix this? Do we scream
that ppplogin is a shell script, that perl is at the /usr sharability
and that people who replace it level, and that people who compile
with a compiled program are doing it for specific CPUs are doing
something wrong? Do we add a layer something wrong? Do we add a layer
of indirection to /etc/passwd, so of indirection to #! lines, so
that the login program looks for that the kernel looks for
ppplogin in several places? perl in several places?
Of course not. We simply Of course not. We simply
give the file a constant name. give the file a constant name.
We can use symlinks if necessary We can use symlinks if necessary
to change its physical location, to change its physical location,
and in particular to change its and in particular to change its
sharing level; but we guarantee sharing level; but we guarantee
that one name can always be used that one name can always be used
to access the file. to access the file.
------------------------------------------------------------------------
None of this is controversial. Everyone likes constant names. Everyone
accesses ppplogin and perl through /usr even though they may be more or
less sharable than /usr. Sharing problems are solved by symlinks; other
indirection mechanisms are neither necessary nor desirable.
I hope it's clear now what ``sharability is not constant'' means. Using
separate namespaces for machine-dependent files and machine-independent
files---like using separate namespaces for third-party packages and
system packages---destroys the ability of other programs to access the
files through long-term names.