On 09-10-14 02:17, Henrique de Moraes Holschuh wrote: > 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)?
Actually, I was really thinking about the situation where dpkg-statoverride AND debconf were NOT used. dbconfig-common allows a package to specify the ownership and permissions of the configuration file. The package may or may not do this via debconf (cacti currently does not). If a local admin decides that the ownership and/or permissions need to be different dbconfig-common should honor that when updating the package. Until know (hence RC) dbconfig-common changed the ownership and permissions unconditionally to the ownership and permissions requested by the package (unless dpkg-statoverride was used by the admin), which may not be what the admin wants (and as you state below may not reflect the situation). > 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. But this indeed is a good idea. Lots more logic to add, but indeed. Annoying thing is that the script that actually does the file writing may be called manually as well. Let me ponder on this some time. > 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. Sure, but AFAICT that is not the case here. > 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? Not applicable for the bug at hand, because there never was a question to the user. Just hard-coding in the package, which I think is acceptable, as well as it should be acceptable that the package leaves it to dbconfig-common to just do-the-right-thing in this case. Paul
signature.asc
Description: OpenPGP digital signature
