On Wed, Mar 12, 2003 at 10:24:49PM +0100, Thomas Hood wrote: > On Wed, 2003-03-12 at 18:03, Joey Hess wrote: > > To put it another way, this is something that an admin can hack around > > as they are setting up a diskless type system. It needs no special > > support from Debian, though we should document that /var/run must be > > available before the network is brought up and could suggest that both > > /var's have links to a /run directory. Of course if d-i got support for > > setting up diskless systems, it would be modified to do that for the > > admin. > > We then can just move anything we like into /var/run, and stop worrying > > about the issue. Seems reasonable to me. > Yes, that's the essence of it. One still does need to worry > about systems that have already been set up such that /var/run > doesn't meet the new criteria, and which would break if > early-accessed state files were suddenly moved there. How > should this be phased in? Announce at sarge release time that > "/var/run must henceforth be rw and network-independent", and > start moving files to /var/run in post-sarge package releases? Well, aside from the fact that it would be nice to fix this in sarge, Continuing to use /var/run as the canonical location complicates things a bit for the mtab case. The 'grep -v rootfs /proc/mounts' approach ought to work, but now instead of being able to just run 'mount /run; grep ...', we would either have to guess at a list of needed mount points (/var, /var/run, /run) and try them all, first making sure they're not network-based; or resign ourselves to not getting any other interesting information mount might've wanted to give us about local devices that were mounted at boot time. -- Steve Langasek postmodern programmer
Attachment:
pgpEkxqJGhtty.pgp
Description: PGP signature