So I got to prototyping this, just to play around with it and see what worked. Then I was reading a thread on debian-mentors about Apache configuration, and I remembered how much of a pain that is currently. It occurred to me that a merging system could perhaps be used to make this sane. I'd like to think about this a bit and see if it affects any design decisions, so that this could be supported in the future at least. The basic idea would be for the package to modify a copy of the saved config file, rather than basing its modifications on the installed file. Example:
- Package P wants to add a stanza to /etc/shared.conf - P asks for a copy of /etc/shared.conf to modify; we give it the installed copy - P makes its modifications and provides the resulting config file - We present the result as a proposed config file merge, as in the simple case discussed in previous messages in this thread - We store /etc/shared.conf as the "last known" revision for P - we apply the changes ...time passes... - A new version of package P comes along and wants to apply the same changes to /etc/shared.conf, not knowing if they are already present - P asks for a copy of /etc/shared.conf to modify, we give it the "last known" revision - P finds its changes already present, and no changes are made ...time passes, the admin decides he needs to change something that was added by P, and does so... - A new version of package P is installed. the above scenario repeats; it knows that it has already added its changes, without regard for whether they are actually present in the current /etc/shared.conf. The admin's changes are preserved, and disaster averted. ...time passes, and package P's needs change... - A new version of package P needs to make a different change to /etc/shared.conf, perhaps even one overlapping with the old change - P asks for the "last known" revision of /etc/shared.conf, applies its changes - We attempt to merge those changes into /etc/shared.conf. If they do not overlap with the admin's changes, then we present the result as a merge. If they do overlap, then a conflict results, and we resolve it as for the usual case. - We apply the changes requested by P to the "last known" revision, indicating that they have been resolved. Future releases of P find their changes already applied, and are satisfied. Similar actions would take place independently for each package which modifies the configuration file. Each package would be modifying its own view of the config file as it last saw it, and the changes merged into the installed version. Each new change made by the package only needs to be resolved once This scheme would provide for shared configuration files with the same user experience as configuration files which are owned by a single package. The only implementation detail is that we keep track of a separate revision of the config file for each package which modifies it. This does not seem like a high price to pay. This leads into a continuation of the question of how to store these files. Warn me now if using RCS in this application would bother you, because it's starting to look like it might be a good fit. -- - mdz