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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141009001759.gb31...@khazad-dum.debian.net