On Wed, Oct 23, 2002 at 08:10:43PM -0400, Matt Zimmerman wrote:
> On Wed, Oct 23, 2002 at 02:02:12PM -0500, Branden Robinson wrote:
> > 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.
Well, Joey Hess is of the opinion that "manage this config file with
debconf"-style questions are Evil and Wrong.
So, assuming I want to get with the Debconf orthodoxy, I would be
changing my config scripts to eliminate this sort of prompting.
> 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.
Here we run into a problem:
* For most packages, the "other maintainer script" is going to be the
postinst. In fact it's difficult for me to imagine a scenario when
anything but the postinst would be generating a config file.[1]
* The postinst, by definition, runs during the configuration phase.
Your proposal is going to pull us farther away from the utopia of
being able to handle all interactivity before packages are even
unpacked, a la dpkg-preconfigure. While dpkg's conffile
prompts already violate this, they *can* be replaced with pre-unpack
prompting, because dpkg-preconfigure can suck new conffiles out of a
package just as well as it can config and templates files.
Non-conffile config files cannot enjoy this luxury, because they don't
exist within the package.
* On the other hand, if we're doing an upgrade instead of an install,
the tool(s) we use to generate the config file may already be on the
system at "pre-configure time". However, if those tools change, and
a package's .config script needs to be able to use the
config-generation tool that's in the corresponding version of the
package, you'd need to have a way of declaring this requirement so
that config file generation could be deferred to package
configuration. Not to mention the fact that the runtime dependencies
of the tools used to generate the configuration files would need to be
present at pre-configure time. Oy vey.
[Time passes.]
Well, after a brief discussion on IRC with Matt and Adam Heath, the
latter of the Debian Dpkg Development Team, I guess we might as well
forge ahead with file update prompting in the postinst. Dpkg may or may
not implement technologies to make our job easier. We'll find out
debconf prompting as postinst time is felt by the users of XFree86 to be
too high a price to pay for conffile-style handling of generated
configuration files.
> 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).
Why not just a checksum? Do you have a specific application in mind, or
do you think the copy is a good idea for the sake of people cleverer
than we? :)
> 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?).
As you said, this is really two different questions:
1) generated file only / existing file only / merge
2) if merge:
prompt for review on problems / always prompt for review
I think the latter is a prime candidate for a shared template that is
used system-wide.
If someone wants to implement object-based debconf templates with
inheritance, then we might want to consider making it package specific.
:)
> 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.
This paragraph struck me as coming out of left field when I first read
it, but IRC held clarification.
The idea is that we want the templates that ask the user about the
config file handling (questions 1 and 2 above) to be standardized; to
look and work the same way for all packages, since this is supposed to
be a general solution and not just one for XFree86.
So, one will ultimately need a Debian package that contains these
templates. Each source package that uses this configuration-file
handling mechanism would, as part of its package build, copy those
shared templates into its own templates file, and declare a package
dependency on a tool that would be invoked from the postinst -- after
the new configuration file has been generated -- to perform the
prompting described.
However, for trial-run purposes in XFree86, I'll probably just
encapsulate all of this inside my own package. If the concept flies, it
will be broken out into its own package.
> Open questions:
I see these two questions as related.
> - 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"
As debconf is itself configured using debconf questions (default
frontend and question priority), so too should this config file handler
be configured when it is installed, giving the user the chance to set a
global policy for configuration file handling.
Since package maintainers will not be expected to have to manage this
sort of thing on their own -- we won't have to trust them to write their
if statements correctly, in other words :) -- I propose we have shared
templates like this.
* Template: shared/mdz-config/merge-policy
Type: select
Choices: always keep existing config, \
always use generated config, \
always merge existing and generate configs, \
always prompt
The last choice effectively means "handle on a per-package (actually
per-config-file) basis.
* Template: shared/mdz-config/diff-viewing-policy
Type: select
Choices: always view diffs between existing and generated config, \
only view diffs when merging
I'm not sure we should have an option for "never view diffs even if
there is a problem merging", as that could cause the system to break.
I'm also not sure it's worthwhile having an "always prompt" choice as we
do with the merge-policy. That just seems excessively tedious.
> 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.
Well, there are two ways you could do it:
1) Make it package specific: /var/lib/mdz-config/packagename, I guess.
This gets chancy if there are many config files and they are in a
weird hierarchy in /etc, though, and especially tricky if there are
multiple config files in the same package with the same basename.
2) Make it mirror /etc. I.e., /var/lib/mdz-config/X11 would "mirror"
/etc/X11. This solves the problems in 1) but IMO it's ugly.
There may not be enough packages going hog-wild with generate config
files for 1) to be a problem, though.
> - 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?
I'm not sure what you're asking here. We would write the templates with
debconf substitution variables in them, and then mdz-config would
db_subst the config file name in before "db_input"ing the question.
Might be a good idea to get Joey Hess's input on this sort of thing
before pulling mdz-config into its own package. There might be
consequences of db_subst usage in shared templates that I do not
anticipate.
Oh, wait, I know what you mean. We can't just blindly append the
mdz-config templates to each package's templates file every time the
package is built. Hmm, yup. Going to need Joey Hess's assistance on
that problem, but it's not a problem for prototyping this in
xserver-xfree86.
[1] Some packages do need a way for their prerm scripts to invoke another
package's postinst script; see xdm's prerm file for an example of when
this sort of action is necessary. (Essentially, you have multiple
packages on the system providing the same interface, and the default is
removed -- so you need to ensure that the new default is configured.)
--
G. Branden Robinson | I suspect Linus wrote that in a
Debian GNU/Linux | complicated way only to be able to
branden@debian.org | have that comment in there.
http://people.debian.org/~branden/ | -- Lars Wirzenius
Attachment:
pgp9qXWgkFdz2.pgp
Description: PGP signature