Re: Bug#720517: configuration files, ownership and dpkg-statoverride
On Wed, 08 Oct 2014, Paul Gevers wrote:
> Thanks for the careful response. And no, as mentioned above, I didn't
> mean to use dpkg-statoverride itself. dbconfig-common uses debconf and
> ufc to manage the configuration files. However, dbconfig-common checks
> with dpkg-statoverride if the configuration file is registered there and
> takes action if it is. However, currently it relies only on
> dpkg-statoverride to know if the ownership of the configuration file
> should be different, I want dbconfig-common to leave the ownership as it
> is if the file already exists.
It looks like your problem is the situation where you have dpkg-statoverride
information and it contradicts whatever is in debconf (or the filesystem,
for that matter)?
In that case, it is an operator error: I suggest you inform him about it and
refuse to continue. There's no other safe choice in the general case,
AFAIK.
Of course, it might happen that you have specific knowledge (such as you
know the dpkg-statoverride information was added in error by a previous
version of the package _and_ the information in the statoverride database
exactly matches the one the bug would have caused) which allows you to
automatically repair the problem, instead.
And if we're talking about an initial question (i.e. there is no conflict
because there's nothing in the debconf database yet), then wouldn't using
the dpkg-statoverride information as a "pre-seed" _and_ not allowing it to
be overriden through debconf (i.e. don't ask the user about it at all) solve
the issue?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: