* 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
