Saving state, but not to /var

OK, if you’re a zealot and want ALL your state data saved to /var, you can pretty much forget it :evil:Here’s the reasons why it’s a bad idea for a package like baselayout- /var is not guaranteed to be always available. In fact, we jump through a lot of hoops to work without /usr available too, but we’re talking about saving state.Another reason why saving to /var is bad is because I’ve been toying with the idea of making “rc single” really single user. This means that when the localmount service stops it unmounts all local disks aside from /, and possibly remounting / ro as well. Now, in this state, the user can reasonably do “rc default” and expect everything to spring back to life. Hard to do when your state data on /var isn’t there anymore. Also, this is event driven like upstart. In this state the user could insert a pcmcia network card which raises a kernel uevent which triggers hotplug to start net.eth0. net.eth0 depends on localmount for /var, so localmount starts. localmount needs checkfs, so that starts, etc etc.I hear people clamoring for upstart in Gentoo- you have already got its functionality :)There are many other reasons why /var could suddenly drop. So we to store our data somewhere on /. The only guaranteed directories to exist are /dev /bin /etc /lib /sbin. We already have /lib/rcscripts to store things all things baselayout, so /lib/rcscripts/init.d seems like a good choice.So taking that as a given, why not just keep /lib/rcscripts/init.d mounted as tmpfs? It doesn’t take that much space (around 200k tops) and for BSD users- well, we loose the allocated space, but no reason why the kernel can’t be sensible and move it to swap. This should make everyone happy and remove around 60 lines of code from /sbin/rc which is no bad thing. So if you have an opinion, then please chime in :)