You're making this way more complicated than it needs to be. For 3rd party stuff, I put the source tree in /usr/lyndon/src/<foo>, adjust the mkfiles to install in /usr/lyndon/bin/$objtype, and say 'mk install'. I keep a shadow man tree under /usr/lyndon/lib/man, and then bind it all on top of the system directories:
bind -a $home/bin/rc /bin bind -a $home/bin/rcaux /bin/aux bind -a $home/bin/$cputype /bin bind -a $home/lib/man/1 /sys/man/1 bind -a $home/lib/man/2 /sys/man/2 bind -a $home/lib/man/3 /sys/man/3 bind -a $home/lib/man/4 /sys/man/4 bind -a $home/lib/man/5 /sys/man/5 bind -a $home/lib/man/6 /sys/man/6 bind -a $home/lib/man/7 /sys/man/7 bind -a $home/lib/man/8 /sys/man/8 (I use this for contrib packages as well, after getting burned a few times with contrib stuff breaking builds in /sys/src. Rather than use the package tool I copy the sources into $home/src and build as above. The extra work is minimal.) If you need to distinguish between your own and site-wide 3rd-party bits, create a new user to own the public 3rd party code, mirror the above structure, and do the appropriate binds in the system-wide namespace files. The only time I contemplate using a /bin/<foo> subdirectory is when there are significant command name collisions. Over the last 10+ years it's only happened to me once. It's almost always easier to just rename the conflicting file. To use Plan 9 properly you must understand what namespaces provide, and how to manipulate them. --lyndon
