Feature changed by: Stephan Kulow (coolo) Feature #306411, revision 8 Title: Configuration files merge openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Michal Hrusecky (-miska-) Description: If we want to make our distribution friendly even to advanced users, I think that we shouldn't touch users configuration files. Luckily this isn't problem as in spec file Ican state that this file is configuration and I don't want to replace it if user did some manual changes. Or I can say that I want to replace it and keep backup of original one. But what I'm missing is some tool to easily merge these files. In Gentoo there is etc-update (http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3&chap=4#doc_chap2) or dispatch-conf (http://en.gentoo-wiki.com/wiki/Dispatch-conf) . I'll describe more precisely what feature I'm missing and why I think it's needed. Let's say that I've got some package and there was quite big change in package default configuration file which will affect most of the users. On the other hand users can have pretty complicated constructions in their configuration files and if they did something like that, it's quite possible that they don't need to update their configuration file. So it is needed to tell users that if they are experiencing problems it is most likely because they touched default configuration. I can take care of it manually, mention it in various README and such, but more easier way would be following. User installs some packages. At the end of zypper or yast installation there will be warning "You've got 42 configuration files to merge, please run etc-update/dispatch-conf/whatever". Then user will run some easy interactive tool which will state which configuration files can use some manual merging, it will allow user to see difference between them and let him choose which one he wants or let him merge them manually somehow. Same warning about unmerged configuration files should appear each time user installs something, no matter if this installation didn't add any conflict, until all conflicts are fixed. User will be warned about possible problems, hacker can play with it and keep his changes against distribution defaults and ordinary user will just click on "use distribution default for all" if he ever encounter such a problem (shouldn't happen as ordinary user wouldn't touch configuration files). I explained basic expected work flow, so now what I think should be supported: * detect configuration files, their conflicts and allow their merge - this shouldn't be a big problem as rpm already stores conflicting files as .rpmnew/.rpmold * we probably want to keep even old versions to support three way merge to achieve even better results * if we are already storing these configuration files, maybe we should let users to backup their own changes as well, add support for versioning these configuration files * warn user that he has conflicts in configuration files - will require a little bit yast/zypper integration * merging tool should support both console and graphical interface (maybe use yast as possible frontend) * support for various formats (expandable by plugins) - ordinary diff may not be the best tool for merging XML files or ini files * ordinary user who don't change anything shouldn't need to know about this tool Relations: - Debian-like dist-upgrade live system full version upgrade (feature/id: 305634) Discussion: #1: Michal Hrusecky (-miska-) (2009-06-02 09:49:38) I was thinking about this a little bit more and if we want to support some kind of versioning and we want to use plugins for getting differences, it may be a good idea to request that plugins will be capable not only of producing nice output of difference between configuration files, but it probably should be able to apply it (behave not only as a 'diff', but also as a 'patch'). And we can build some simple version control system on top of it. Advantages: * can handle non-plain text files better (via plugins) * we can implement feature to discard or merge several commits into one to save space/make commit log more readable * can handle nicelly even insane configuration files like sqlite database or compressed directory with configuration files or any other binary format Disadvantages: * probably worse handling of text files * another thing to maintain/possible source of bugs + #2: Stephan Kulow (coolo) (2009-06-09 11:51:14) + this sounds like a lot of work to do right and with little gain. We + lived quite well for years without it and whatever tool you come up + will create new problems, there won't be a perfect tool. Applications + with very bizzare config format usually come with their own + configuration update tool that can be called from %post + So I would put very low imporance on this. -- openSUSE Feature: https://features.opensuse.org/306411