>>>>> Dale Scheetz writes: DS> I still see an implication that the two are distinct and DS> separate, although it is, indeed, vague.
It is vague by design. Thomas Bushnell, chief architect of the Hurd, was partly involved in the creation of the FSSTND. He tried hard to make sure that having / and /usr be the same directory wasn't a violation of the standard. >> Also note that the hurd allows for the boot process to have some >> of the binaries in one physical region and the bulk of the >> binaries in another physical region even though they show up in >> the same directory. DS> That's a neat trick. How does it deal with binaries on two DS> separate phisical regions that have the same name, when both DS> regions are mapped to the same directory? As others said, this feature is not yet implemented, but the basic idea is that the user would have different ways (config file, command line options, etc) of specifying the relative priorities of files that come from different places. In this case, we'd just tell shadowfs that /usr was higher priority than /. DS> There is still a problem if you re-install/upgrade ae, as it will DS> put the script back in place on the upgrade, but then vi will do DS> the same, so it will depend on the order of upgrade as to which DS> gets control. Aha. That's one more reason to make ae work its /bin/vi magic in its postinst rather than the package itself. Feel free to ask me if you want help with the shell scripting for this. DS> Doesn't dpkg complain when it tries to "overwrite" a file from DS> one package with the same file from another? Not by default anymore. Somebody turned that feature off (I think because of the problems that come up when packages are reorganized). DS> I suspect that vi is only a tiny part of the problem of linking DS> /usr to /. This not only makes /usr/bin isomorphic to /bin, but DS> /usr/lib and /lib, and /usr/sbin and /sbin also get overlapped. I DS> can't believe that ae represents the only file overlap in that DS> whole collection. So far, it's the only overlap in the whole collection that I've noticed. We'll deal with the others as we notice them. Thanks, -- Gordon Matzigkeit <[EMAIL PROTECTED]> //\ I'm a FIG (http://www.fig.org/) Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)
