I agree with Manoj when he says: > I think it is premature to [r]atify into policy an action > that has not been fully decided upon, and has not yet had > all the kinks ironed out [...]
However, there does need to be some discussion of what properties /run/ will have. Early in the debian-devel discussion it was suggested that /run/ be required to be RAM-based, that it be initialised with a skeleton, etc. As the discussion went on there seemed to be agreement that /run/'s properties should be determined by the problem it is solving, namely, the problem of there being nowhere to store runtime state prior to the availability of /var/run/ on a system that mounts /var/ from the network. To solve this problem, /run/ needs to be available locally so that it can be mounted early, probably by /etc/rcS.d/S35mountall.sh . I would argue that for the present /run/ should be so defined, and otherwise should be implemented as simply as possible. Proposed list of properties of /run/: * Available and empty after /etc/rcS.d/S35mountall.sh runs * No skeleton * Files stored in /run/ are not "reaped" * A program should *only* use /run/ if it *must* do so because it has to store something before /var/run/ becomes available on systems that mount /var/ over NFS. -- Thomas Hood <[EMAIL PROTECTED]>