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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
