On Thu, Aug 12, 2004 at 01:01:34PM -0700, Brian Nelson wrote: > On Thu, Aug 12, 2004 at 12:28:42PM -0600, Paul E Condon wrote: > > On Thu, Aug 12, 2004 at 08:43:04AM +1000, Cameron Hutchison wrote: > > > Once upon a time Jason Rennie said... > > > > On Mon, Aug 09, 2004 at 02:09:08AM -0700, Brian Nelson wrote: > > > > > The debconf database is nothing more than a temporary cache of answers > > > > > gotten from the user. Debconf will regenerate this data by asking any > > > > > questions it needs to. > > > > > > > > If the Debian designers had this attitude, everything would go into > > > > /var/cache: > > > > > > > > What, you want to run oowriter? Oops, just deleted that from my > > > > cache. Downloading openoffice.org-bin.deb from www.debian.org. > > > > Please wait. > > > > > > Worse than that. All configuration files could be stored in /var/cache > > > with this logic, since vi can just regenerate this data by getting you to > > > type it in again. > > > > > > As I see it, if debconf is asking you the questions again, *it* is not > > > regenerating the data, but *you* are. > > > > > > > I've looked at the contents of /var/cache/debconf on my machine. I > > can't make out what it really contains. It certainly doesn't seem to > > contain the answers that I gave to configuration questions during > > package installation. > > $ grep Value: /var/cache/debconf/config.dat > > are all answers you either gave or debconf gave defaults for (depending > on your debconf priority setting). >
Brian, you are correct. I did not look far enough. The stanzas that I looked at did not contain Value: clause, but I see others that do. I also see my selection of initial sources.list action "edit by hand", but no indication of what my edits were. Yes, I did edit sources.list by hand, and backing up /var/cache/debconf/config.dat would not save those edits. > > As I said in a earlier post, if you are concerned that it *does* contain > > information that should be checkpointed, you can move it to /etc and > > either put a softlink in /var/cache, or edit /etc/debconf.conf to point > > to its new location within /etc > > > > Someone who mistrusts the design of debconf might try renaming > > /var/cache/debconf to /var/cache/hide.debconf and see what happens. > > Is a new /var/cache/debconf created automatically? > > You should never remove directories in /var/cache. Files must be > regenerated, but directories do not need to be, so something may break > if you do. > > See > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARCACHEAPPLICATIONCACHEDATA > adding fuel to the fire, here is what I find in the above: quote _________________________________________________________________ Purpose /var/cache is intended for cached data from applications. Such data is locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. Unlike /var/spool, the cached files can be deleted without data loss. The data must remain valid between invocations of the application and rebooting the system. Files located under /var/cache may be expired in an application specific manner, by the system administrator, or both. The application must always be able to recover from manual deletion of these files (generally because of a disk space shortage). No other requirements are made on the data format of the cache directories. Rationale The existence of a separate directory for cached data allows system administrators to set different disk and backup policies from other directories in /var. --------------------------------------------------------------------- end quote If the data in /var is easily regenerated, why is backup of these data mentioned in the rationale as a justification for separate directories? It seems to me that at least one of the contributers to the standard expected that at least some sys-admins would want to backup some of the data in /var. The standard guarentees the possibility of backup of selected parts. I conclude that the OP's belief that the wording of the FHS, apparently precludes ever needing to backup /var is mistaken. So, OP, do backup whatever parts of /var you feel you need to preserve. -- Paul E Condon [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]