Configuration file handling (Re: [desktop] Unix configuration nightmare)
On Wed, Oct 23, 2002 at 02:02:12PM -0500, Branden Robinson wrote:
> Yes, now that I've written this mail, I've pretty much made up my mind.
> I like your idea. If the user dicks with the autogenerated file, we
> slam on the brakes and toss him into the manual configuration ghetto
> where he belongs. His changes are respected and he gets to RTF
> XF86Config-4(5) page.
> [...]
> Matt, I'd be more than happy to use xfree86 in unstable as a testbed for
> your proposal. If you agree, let's migrate this subthread over to
> debian-x.
OK, let's spec things out a bit, then.
I don't think that existing .config handling necessarily needs to change at
this point, unless we want to provide a standard way to suppress all
attempts at automatic configuration for a particular config file.
In other maintainer scripts, we need to be able to say "I have generated a
configuration file /tmp/blah as a possible replacement for /etc/foo/bar." At
that point, the maintainer script is done with the file, and passes control
to us.
We check again whether the file has been modified since last time by
comparing it to a saved copy or checksum (the copy is optional, but gives
much more flexibility than storing only a checksum). If it has not been
modified, we overwrite the existing config with the new one, and update the
saved copy to match.
If the generated configuration file is identical to the existing one, then
by some miracle, the user has made changes identical to what we would have
made, and we update our saved copy of the config file and exit.
If the files are different, then we attempt a merge, check whether it was
successful, and interact with the user via debconf, explaining the situation
and the result of the merge attempt (displaying a diff if the user cares
about such things). At the end of the interaction, we should have decided
on one of these courses of action:
- Throw away the admin's changes to the file and replace it with the new one
entirely (conffile 'y')
- Ignore the package maintainer's changes to the file and keep the existing
one (conffile 'n')
- Merge the package maintainer's changes and give the user a chance to fix
things up manually before continuing
- (this option is only available if the merge was successful)
Merge the package maintainer's changes and continue without further
interaction
In the common cases, this should be possible with a single prompt, though it
could be split into two phases or selected from either a "simple" or
"advanced" method, or even suppressed entirely for novice users if a sane
default action sequence could be decided (always preserve? merge, and if
that fails, preserve? warn?).
At package build time, the source package machinery only needs to indicate
which binary packages will be making use of the infrastructure, and a helper
will ensure that the necessary templates are included and generate
dependency substitutions. Rebuilding a package will automatically pull in
the latest, best-translated templates from the helper.
Open questions:
- What should happen at preconfiguration time to minimize interaction for
novice users?
- What sort of preferences would be useful, either at a global scope or a
per-package scope? "always leave my foobar config alone" "always merge
my changes if there are no merge conflicts"
Implementation issues:
- How to store the saved config files, so that it is intuitively obvious to
which package they belong, and their installed location, so that they are
conveniently available to the admin? This should be a public interface.
- Will it be necessary or desirable to modify debhelper so that there is a
substitution interface for templates, similar to what is done for
maintainer scripts?
--
- mdz
Reply to: