Subject: Re: /var/db/pkg
To: Manuel Bouyer <email@example.com>
From: David Burren <firstname.lastname@example.org>
Date: 05/23/2000 09:15:30
Manuel Bouyer wrote:
> This is also my opinion, but for another reason: on my servers,
> /var is a separate file system, and can be quite large. To have a backup of the
> system I need /var as well, for /var/db/pkg (I don't care much about the
> logs, interesting ones are replicated on loghosts anyway).
> I think /var should
> only contain log files or files that can be regenerated from the system.
/var is meant to be state local to this host. Dynamic files that change
more often than the rest of /, amongst other characteristics.
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
Am I mistaken?
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 would favour keeping the state under /usr/pkg, but definitely not for