[Debconf-devel] Bug#864875: debconf: frontend exits with status 10 after last upgrade when /var/cache is tmpfs

Niko Tyni ntyni at debian.org
Thu Feb 15 18:58:29 UTC 2018


On Thu, Feb 15, 2018 at 03:26:50PM +0000, Colin Watson wrote:
> On Thu, Feb 15, 2018 at 10:39:15AM +0000, Dominic Hargreaves wrote:
> > The debconf database *is* in /var/cache so I don't know how anything
> > can be expected to work after it's wiped. But according to the FHS
> > what Franz is doing is completely allowable...
> > 
> > CCing the Debconf developers in case they can shed any light on this.
> 
> Sounds like the long-known https://bugs.debian.org/247134.  It probably
> needs to be dealt with at some point, but oh goodness the anticipated
> migration pain ...

I'm a bit surprised by #247134. Doesn't the "debconf is not a registry"
mantra imply that all data in /var/cache/debconf should be possible to
regenerate from config files in /etc/ and the like?

To elaborate, I always thought that debconf based maintainer scripts
need to store all configuration information somewhere else in the file
system, and read those files back in for default values when re-asking
the questions (possibly overriding whatever is in the debconf database
in case the system administrator has changed the external configuration
in between.)

In the context of this bug, I'd expect dbconfig-common to read in
/etc/dbconfig-common/request-tracker4.conf and fill in the empty
(nuked) debconf database based on that.
-- 
Niko Tyni   ntyni at debian.org



More information about the Debconf-devel mailing list