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

Re: Questionable conffile handling in connection with debconf



>>>>> "Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:

    Anthony> --raC6veAxrt5nqIoY Content-Type: text/plain;
    Anthony> charset=us-ascii Content-Transfer-Encoding:
    Anthony> quoted-printable

    Anthony> On Thu, Nov 30, 2000 at 06:30:44PM -0500, Matt Zimmerman
    Anthony> wrote:
    >> As I understand policy (see the excerpt at the end of this
    >> message), conffiles should nev=
    Anthony> er be
    >> modified in maintainer scripts.  Configuration files should be
    >> distribute=
    Anthony> d as
    >> part of the package (either as conffiles or not), or else
    >> created and man=
    Anthony> aged
    >> by maintainer scripts, but not both. =20

    Anthony> If a configuration is shipped as part of the package it
    Anthony> *must* be declared as a conffile, otherwise the user's
    Anthony> changes will be lost on upgrade. But otherwise, yes.

There is another option, which I have preferred in my openafs and krb5
packages.  I ship a configuration template (generally in
/usr/share/doc/package/examplaes).  I install that template in /etc if
the configuration file is not found.


In my config script, I first parse the configuration file, trying to
see if the user has changed any of the options I care about.  If so, I
db_set those changes into debconf.

Note that since this happens in the config script, I do not look at my
own initial template, as that hasn't been installed yet.  If for some
reason the user has created a config file before installing my
package, their defaults seed Debconf.  I consider this a feature.

After parsing the config files, I then db_input my questions.
Normally, on upgrade, they will never see the questions, but if they
run dpkg-reconfigure they will see their changes.

Then in the postinst, I use a sed or perl -ine invocation to edit the
config file in place to take values from debconf and put them into the
configuration file.

I do not mark these configuration files as conffiles.  I consider it
fairly close to mortal sin to mark a configuration file you modify in
the maintainer script as a conffile, as it more or less guarantees
that the user will see questions on every upgrade.  Being able to
upgrade non-interactively is a critical feature.

I think there is one case where I actually just clobber the config
file from debconf but in that case, I fully enumerate the
configuration of that file from within debconf.  Even so, if someone
were to open a bug on this, I would fix.

If this style of configuration handling becomes common, we may want to
have sets of configuration parsing utilities packaged for parsing
common file formats and editing them in place.  You'd need some
mechanism to specify that a package must be installed before
preconfiguration--pre-depends is not good enough.

--Sam



Reply to: