Jamie Wilkinson wrote: > That is right! The core of the matter is not whether > filesystems need to be mounted over the network or not, > but whether the parts of the filesystem you are attempting > to write to are on the root filesystem or not.
The essence of /run/ had better not include that it be a directory on the root filesystem, because the current proposal is that it be possible for /run/ to be a RAM-based filesystem on systems with read-only root media. [... in another message:] > Thus we don't need to compare /run to /var/run, but make /run available > for the same purposes of the entirety of /var but only in the case that > a required subdirectory of /var doesn't exist. I balk at this. IMHO we should call the new directory '/run/' if and only if we are going to use it for the same purposes for which we use /var/run/. If the new directory is to be a whole parallel local var hierarchy then we should call it something like '/lvar/'. However, I don't think we need a whole parallel local var. > This works for the case that > some programs need a /var/run and some need a /var/state > and some need a /var/lib for their file; /var/state/ is deprecated. Files stored in the proposed new directory will be lost on reboot, so it is not suited to be a "lib" directory. > there will be so few programs actually > using /run that there is no need to separate /run into further > subdirectories for each of the /var subdirectories. /var/ contains thirteen subdirectories on my system. For which of these is a guaranteed-to-be-local variant needed? So far, a case has been made only for "run". With thanks for your /run/ patches... -- Thomas Hood <[EMAIL PROTECTED]>
