Subject: Re: /var/db/pkg
To: David Burren <email@example.com>
From: Manuel Bouyer <firstname.lastname@example.org>
Date: 05/23/2000 17:56:23
On Tue, May 23, 2000 at 09:15:30AM +1000, David Burren wrote:
> /var is meant to be state local to this host. Dynamic files that change
> more often than the rest of /, amongst other characteristics.
/var/ multi-purpose log, temporary, transient, and spool files
> My understanding is that /var/db is meant to be primarily databases that
> are preserved across reboots (as distinct from /var/run). E.g. dhcpd
> state files.
> Am I mistaken?
Ok, but this is not critical piece of information.
> Where else would you store this data? Under /usr? Keep in mind that
> this is often (ok, ok, so that's a relative term) NFS-shared between a
> cluster of machines. If the data reflects the the contents of /usr,
> then somewhere under /usr sounds very appropriate. Otherwise /var
> (whether it's part of / or not) has historically been a sensible
> In any case, relying on /var to _only_ have throwaway data is a flawed
> policy that will bite you (or someone else) sooner or later. I guess it
> boils down to a question of how much pain you're willing to go through
> if/when you have to go to backups. If you're going to exclude data from
> your backups, be sure you don't do it with too broad a cut (sure,
> filesystem-level dumps may make your choice harder, but symlinks are
I expect to get back a usefull system by restoring anything but /var from
backups (this is how I understand "temporary, transient").
The only think that prevent me from doing this rigth now is the package
Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr