[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#720517: configuration files, ownership and dpkg-statoverride

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,

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.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: