Sweet. Since I'm the beggar and not the one actually doing the spec, I humbly make some suggestions.
One is a stop-gap measure to deal with config files as they currently are. What you need for a merge are three files: (1) the old config file, unmodified, (2) the old config file, modified, and (3) the new config file. A character-level diff between (1) and (2) will give you both the changes and the contexts of the user changes. (You may need to distinguish between insertions, deletions, and modications.) A char- level diff of (1) and (3) will give system changes. You can determine from the the system changes if something is added, and you just add it. You can determine from the system changes if something was deleted; in that case, see if there are any user changes in those contexts and delete those user changes from your memory. (Well, be smart about things like additions and how far a context extends, etc.) Now you can whole-sale user changes into the new config file. There are perhaps better ways to do this. The next solution is to solve this once and for all. Everybody hates the Windows registry. But that was because it was this huge monolithic database, in a binary format, and it was prone to corruption. On the other hand, modern Windows apps don't use the central registry but instead have per-app and per-user mini-registries. Also, no one complains about MacOS .plist files. plist files are nice because they're ASCII XML files that are per app and per user and they're structured as key/value pairs. In terms of most of the config files I ever had to edit, everything already was key/value or could be contrived to be so. So this isn't a change in semantics, only syntax. With this added structure, blind merges (where all you have are old and new) are relatively trivial, but additionally, updates can be scripted where the install script specifies things about how keys/values from the old file should be combined with the new one. Finally although there are advantages to keeping things together in one file, there may be a good argument for splitting up config files. Some settings are almost never changed, while others are likely to be changed. I'll take an example from Solaris, the files /etc/openwin/server/etc/OWconfig and /usr/openwin/server/etc/OWconfig. IIRC, the former tends to contain standard settings, while the latter contains user settings. Moreover, if anything conflicts, the user settings override. So, I suggest that there always be appname_defaults.xml and appname_user.xml files. Any changes can be specified in the appname_user.xml file, overriding the defaults. When an upgrade is performed, you can just blindly replace appname_defaults.xml. Deprecated fields in appname_user.xml just get ignored. The only situation where we have to be concerned is when a field is not deprecated but the user could supply inappropriate values. Certainly the app can check that at run time, but since this is all XML, you can make the app install script examine the appname_user.xml file and possibly make changes. This can be further layered by allowing users to have corresponding config files somewhere under their home directory, with their personal settings overriding both _user.xml and _defaults.xml. For this, we would need libraries that apps could link to that would provide a specialized config file read/write API. This would then be relatively trivial to drop into existing apps. Find the parts that read config files and replace them with calls to the API. You can keep field names the same and everything. Transitional apps could implement both methods, and we can write smart scripts that actually convert old format files (that are relatively regular) into the new format. Obviously, this transition process would be slow, but we can do it one app at a time, and the best way to allow that to happen is to provide the API and make it easy to use. Note that some things like sendmail that include script chunks in their config files are exceptions. Different apps have different needs. Sometimes, you can embed a chunk of some code or a formula or whatever into XML, but without a specialized editor, that can get ugly. Perhaps a middle ground would be to extra key/value pairs into one XML file and put the scripts into another. -- Meta-bug: Package upgrades don't automagically merge config file changes https://bugs.launchpad.net/bugs/69412 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
