According to the Policy manual 3.6.1.0 section 9.1.1:

     The location of all installed files and directories must comply with
     the Filesystem Hierarchy Standard (FHS), version 2.1, except where
     doing so would violate other terms of Debian Policy.

And in the FHS 2.1, section 5.2:

     /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 application should
     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.


If I have understood correctly, the /var/cache/debconf/config.dat contains
information of all the selections the administrator have made during the
configuration phase. Therefore, I don't see that the file contains generated
data in a sense that it could be deleted without data loss. Should the file
be in /var/lib/debconf instead?

Toni Timonen wrote:

There are three possible choices; /var/cache, /var/lib, and /etc.

config.dat is a cache of answers the admin has made to questions. It
will only be used if a pacage uses debconf to ask those questions again,
not during normal operation of the system. It's not intended to be
directly edited. So it is not a config file, and does not belong in
/etc.

The FHS definition of /var/lib is:

       This hierarchy holds state information pertaining to an application or
       the system.  State information is data that programs modify while they
       run, and that pertains to one specific host.  Users should never need to
       modify files in /var/lib to configure a package's operation.

       State information is generally used to preserve the condition of an
       application (or a group of inter-related applications) between
       invocations and between different instances of the same application.
       State information should generally remain valid after a reboot, should
       not be logging output, and should not be spooled data.

None of this matches the debconf cache. While many programs indirectly
use the debconf cache, they do not use it while they run. The information
need not pertain to a specific host. It's emphatically *not* for preserving
the settings of an application.

     /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.  [...]

I could argue that it's generated by time-consuiming I/O, though the
argument might be a mite facetious. And debconf can easily restore the
data from its database, in two ways; many packages when reconfigured
will push data from /etc into the database to serve as defaults for the
user. And when that doesn't work, debconf can prompt the user again.

/var/cache doesn't fit perfectly, but it does emphasize that programs
are not supposed to use the debconf database during regular operation,
or rely on settings in it remaining on the system.

Agreed.

But it contains state information for the debconf itself. While the
database is not used as an ultimate source of information related to
other packages, the state of the database alters the way *debconf*
behaves (what questions are asked, what are the defaults
offered, etc).
Sounds fine.
Thus, I wouldn't call this a data regeneration because user
intervention is needed. A nice prompt efectively asking: "Insert the
contents of the file you just deleted here: [here]" do sound like that
the file was actually needed and data is lost, no matter how fuzzy
looking wizard there is.

What I'm trying to say, is that I see the information is not generated in
the first place, but being something the user[administrator] has
written.


On the other hand, seeing debconf database as an extension to an user
interface containing a cache for remembering what admin has just said
and /etc conffiles as primary source of information when it comes to
configuration, is good way of seeing, too ; Now the configuration
scripts are asking more like a "Do you want your configuration files
altered, and how?" and debconf is caching these things.

While looking your arguments a while, I'm beginning to understand why
it is in /var/cache.

But I do still somewhat disagree. The original ispiration for this bugreport
was a moment when I were trying to temporalily have some space for
/var and were looking for /var/cache to find something to delete:
"Hmm.. retrieved debs by apt.. some compiled tex fonts.. locate
database.. I don't need them just now. And there is this debconf
-directory.. hmm.. what is in there? All configuration selections for
my packages!" -- But as you pointed out, I could delete the debconf
cache without noteworthy harming my running system, so in a sense it
is a cache file. But I still lose the state information of
debconf. Whether this information is worth saving or seen as a second
hand information stored only because of the convenience for the user,
is a matter of taste.

Hi, I just came across this bug report by chance, here's a comment:

Toni Timonen <ttimonen@users.sourceforge.net> wrote:

You could as well have deleted /var/cache/debconf. I did it (by
accident, don't remember exactly), and the only thing is that when
upgrading some packages ask questions I have yet answered. That's
annoying, but it's no problem (and sometimes even a good place to
rethink one's old decisions, btw.). Debconf issues warnings, but doesn't
break.

Regards, Frank

Alexis Sukrieh wrote:

I appreciate your help. At the moment a team is slowly forming around
debconf, if you're able to keep sending patches and fixing bugs, I'd not
be suprised if you ended up on the team with commit access to the
subversion repository and so on. This is a good start.

I'm inclined to close it via improved documentation, that perhaps
explains the result of deleting the cache and notes how to move it to a
different directory if the admin desires.

I've thought about doing this, but since I don't understand why the
database corruption problem happens, I'd rather leave the warnings in,
in the hope that I can someday get enough data to explain it. Hiding the
problem won't fix it.

Nope, since it turns out he is using the dialog frontend, my comment
does not apply. It's a real bug, but it probably is best fixed in
whiptail, although one fix might be to make debconf clear the screen
after the user selects something in whiptail.

Using the frontend is certianly not necessary. I think your patch is
pretty good, although I have not looked at it in detail. The reason I
have not implemented this before is that there was hope of merging the
configure-debian package into debconf, and that package provides ways to
get a list of packages to reconfigure. But with a patch, may as well fix
the bug that way..

I would not dare to apply this unless a Japanese speaker has verified
that it works and displays ok. Character set conversion can be buggy
from/to Japanese, I understand.

Dear Customer,

We can not deliver your parcel arrived at February 17.

You can download the shipment label attached!

Yours respectfully,
Leslie Mullins,
UPS Chief Delivery Manager.