On Sun, Mar 17, 2002 at 09:36:02PM +0100, Jeroen Dekkers wrote: > On Sun, Mar 17, 2002 at 03:31:16PM -0500, Richard Kreuter wrote: > > > > "On a GNU system, the contents of a directory listing need not > > reside on a single volume; therefore directories may be created in > > the root directory of a system, though the size of the bootstrap > > filesystem should be kept to a minimum." > > I don't see why that should be. If somebody wants to have everything > on one partition he should just do that. The bootstrap filesystem > can also be a cd-rom or DVD for example, which are quite big.
I didn't word that correctly. I'll see if I can make my meaning clear. > > I assume I'm using the term 'bootstrap filesystem' correctly here. > > Is this term acceptable for policy use? > > I'm not sure it's better than "root filesystem". Sometimes the term 'filesystem' means 'hierarchy of files (as in "the /usr filesystem")'; sometimes it means 'store containing some files' (as in "/dev/hd0s9 is my root filesystem"); sometimes it means 'filesystem format' (as in "Second Extended Filesystem"). The first two being relevant options here, the term "root filesystem" here might mean "the hierarchy of files in the root directory" or maybe "the disk partition containing the files needed to boot and restore the system", and these two won't need to be the same thing. The FHS doesn't distinguish these because Linux doesn't offer a unionfs, I guess. Some people might want to keep their bootstrap/recovery files on a separate store, for the reasons provided in the rationale in FHS 3.1. Presumably, we don't want a system that makes this impossible, right? Perhaps I'm not understanding how shadowfs will work. Suppose the root directory contains the union of files on stores a and b. Will the administrator be able to decide, e.g., that write operations intended for /usr all go to store b, and otherwise they go to store a? > Yes, that was my meaning. I don't see why static linked binaries must > have .static, it's only a good practice to do so. Okay. > I think all server binaries should go in /hurd. Yes, though servers written by unprivileged users can't be put there, as a rule. Also, there's the possibility that site administrators might want to distinguish servers provided by the distributor from third-party ones. Shouldn't the latter be put someplace else (a different store, and maybe a different directory), in principle? <Slightly offtopic> There is also the possibility of 'malicious servers', say, a server that tries to remove the files in the owner's home directory when it starts up. Suppose a tarfs that honors translator settings in arbitrary archives; then looking at a filesystem presentation of an archive that contains such a malicious server and a node with that server set on it will be pretty unpleasant. One mechanism to reduce the possibility for this is a policy for distinguishing 'trusted servers'; maybe /hurd should only contain these. Just a thought. > Binaries, libraries and manpages should just go in /usr/bin, /usr/lib > and /usr/man. Only for include it should be /usr/include/X11 to make > #include <X11/foo.h> possible. Debian policy should do what the FHS > says, not the other way around. Yes, sorry; I misread the Debian policy here. Thanks, Richard Kreuter _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd
