it should instead use /var/lib and /var/run ... refer to FHS here: http://www.pathname.com/fhs/2.2/fhs-5.2.html (overview) http://www.pathname.com/fhs/2.2/fhs-5.8.html (/var/lib) http://www.pathname.com/fhs/2.2/fhs-5.13.html (/var/run)
I can see the point of /var/lib, but what has /var/run have to do with /var/state/init.d ? There is no pid, whatever in there.
well, since init.d should not really be maintained across reboots, it seems like it would fit better in /var/run than /var/lib
Put it this way .. since the data is no longer on tmpfs, most of it do not need to be regenerated on reboot. If you want to be technical: 1) after/, before/, need/, provide/, use/ These can be in /var/cache, as they only need to be updated if /etc/runlevels/ change, and are time consuming in calculation (ok, not that much anymore ... 2) broken/, depcache options/, snapshot/, softlevel, softscripts/, started/ These do variable during boot, and could be in /var/run. Problem that I have with splitting these, will be that it will require some extra 'AI' to handle different states (tmpfs, notmps...), and make things more complex.
my point wasnt to say to split up everything or to use just /var/lib or /var/run for whatever reason, i just dont want it using /var/state since it isnt mentioned anywhere in FHS ... where you choose to put it (other than /var/state) is fine with me /var/run seemed like a good choice because it 'contains system information data describing the system since it was booted' ... and although you can start/stop scripts after boot, /var/run still kind of works because it isnt *just* for pid files ... /var/lib looks like a much better choice because it 'holds state information pertaining to an application or the system' ... and it can be retained across reboots so that you dont have to regenerate it like you pointed out since /var/lib allows for that
Fixed on CVS.
