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/commandBut 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:distHere 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.