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

[david@eelf.ddts.net: Re: why do we care about configuration files?]



On Fri Apr 18, 11:15am -0400, Colin Walters wrote:
> Perhaps I've been overly strong with the rhetoric.  Let me give two
> realistic scenarios where this "manage foo with debconf?" fails.

I like your two real-world examples, and I'd like to present a third.

3) Impatient but advanced user
   Somebody who dislikes being asked repeatedly whether or not a
   conffile can be overwritten. This user has tested xserver-xfree86's
   debconf interface, and has taken the time to understand how
   xserver-xfree86's postinst generates the configuration file based on
   the debconf information. He is very confident in it doing the right
   thing, and doesn't want to be bothered on each upgrade about whether
   or not it can overwrite it. More importantly, this user knows full
   well that, in the very rare circumstance where it *does* break, he
   can easily fix it within minutes.

This user will likely feel the same way about almost all
debconf/postinst-managed configuration files, excepting the few which he
knows will break repeatedly. He doesn't want to get asked 50 "may I
overwrite your file?" questions each upgrade. He knows that in the time
spent reading and answering all those questions, he could just has
easily fixed the two cases of breakage. Which he would have to do in
addition to answering the questions, were they forced upon him.

I liked the concept behind your suggestion of "managed" and "unmanaged"
configuration files. I would, however, suggest a slightly different
interface:

1) Package has a configuration file which can (optionally) be managed
   debconf/postinst
2) Package's .config asks, *once* (respecting debconf "seen" flag), the
   following question:

   "File /etc/foo/bar can optionally be managed by this package's
    maintenance scripts in an automated manner. How would you like
    changes to /etc/foo/bar to be handled?

	ask-no: If /etc/foo/bar will be changed, ask first. Default to
	        `no'
       ask-yes: If /etc/foo/bar will be changed, ask first. Default to
                `yes'
     always-no: Never automatically overwrite /etc/foo/bar, don't even
                ask.
    always-yes: Always automatically overwrite /etc/foo/bar, don't even
		ask (warning: dangerous).

				 ask-no
				ask-yes
			       always-no
			       always-yes"

3) That question should be standard amongst all packages, identical. It
   should always be of priority "medium".
4) A standard interface for ask-yes and ask-no would also be required,
   similar to dpkg's conffile handling.

For ask-* interfaces, debconf's "seen" flag should (obviously) be
ignored, since it's *meant* to be asked repeatedly.

After some feedback, I will implement said standard interfaces as
example. I kind of like the idea of
/etc/conffiles/{managed,unmanaged,default}. That could easily be used as
the backend storage for the standard {ask,always}-{no,yes} question.

Attachment: pgpBnjoZCc86n.pgp
Description: PGP signature


Reply to: