Re: Proposed handling of generated configuration files (Re: stop the "manage with debconf" madness)

[Tore Anderson <tore@linpro.no>]

* Matt Zimmerman

 > There was a more recent discussion about the same idea.  A summary of the
 > goals:
 >
 > - Don't try to parse every program's configuration file format
 >
 > - Notice that a non-conffile, autogenerated configuration file has been
 >   modified by the user, and don't lose their changes
 >
 > - Provide 3-way merge functionality to incorporate changes without losing
 >   modifications in the common case (I hear this is coming for conffiles as
 >   well)
 >
 > - Use debconf for prompting
 >
 > - Have all packages do this using a standard toolset, so that all prompting
 >   is consistent and well-translated, and certain defaults can be set
 >   globally (see the threads below for more discussion about this)

  Hey, you just described how how ucf can be used.  Here's a crash course on
 how to use it in package "fnord"'s maintainer scripts:

      fnord.config:
    db_input fnord/something_that_has_no_good_default_answer
    db_go

      fnord.postinst:
    db_get fnord/something_that_has_no_good_default_answer
    cat << _eof > /usr/share/fnord/managed-conffiles/fnord.cf
    # configuration file for fnord.

    setting_with_acceptable_default1 = quux
    setting_with_acceptable_default2 = zoot

    # this variable hasn't got any good default.
    variable_with_no_good_default = $RET
    _eof
    db_stop
    ucf /usr/share/fnord/managed-conffiles/fnord.cf /etc/fnord.cf < /dev/tty

  Lo and behold!  We've just achieved your goals, using tools already in
 the archive!

  If /usr/share/fnord/managed-conffiles/fnord.cf changes, because of
 a dpkg-reconfigure where the user gives another answer, or a upgrade
 where the template has been changed by the maintainer (or a combination),
 and the user has changed /etc/fnord.cf, ucf will pop up a question which
 closely resembles dpkg's counterpart:

    Configuration file `/void/home/tore/ucftest/cf'
     ==> File on system created by you or by a script.
     ==> File also in package provided by package maintainer.
       What would you like to do about it ?  Your options are:
        Y or I  : install the package maintainer's version
        N or O  : keep your currently-installed version
          D     : show the differences between the versions
    (...)

  Local modification will be kept, if the user wants them to be!  So
 there's no reason anyone to supply configuration files with comments
 such as "## don't edit this file; it belongs to the maintainer scrips!",
 even if the file is dynamically created.  The user doesn't need to know
 that whether or not not a conffile or a ucf-handled configuration file.

  But wait!  There's more! -- if you supply the --three-way option to ucf
 in your postinst, the rest of ucf's question looks like this:

        3 or T  : show a thre way difference between current, older,
                  and new versions of the file
          M     : Do a 3 way merge between current, older,
                  and new versions of the file [Very Experimental]

  Exactly what you wanted, yes?

-- 
Tore Anderson