> I don't find that nice. I frequently find myself in the situation where I > desperately want some help from the package management in getting rid of > bogged configurations. I.e. I don't want package management to ignore the > problem of settings. Ingo's proposal is to at least "mark" packages where > merging should be possible. Sounds good to me. But even if merging is not > possible, I want PM to be aware of settings. For example, it should at > least allow me to get rid of any customizations (overridden default > settings) when deinstalling a package. Well, it's certainly fine for the package manager to know that a new version of the file is available, and the older one might be incompatible. Taking Debian/apt as an example (maybe other package managers do better ?), it will try to do a 3-way merge (knowing the previous version of the settings files, the user modified one, and the new one). The problem is : - The merge often fails. Examples are when an option is removed/renamed and was modified, or the file was just reorganized, etc. - Even if the merge succeeds, you're not sure that the merged file will work with the new version of the package. This leaves you with an even worse situation: you're left with only the merged config file, and no trace of any of the original versions. (Debian now keeps the 3 versions next to the file. That solves the problem but clutters the settings directory with a lot of older version of setting files over time). The merge process is also painful to integrate in the package management system. In command-line, Debian will ask what to do each time it encounters such a file, which means you have to wait for the questions as packages are installing. In an UI-based package manager/update application, it's not easy to ask the user what to do in a simple way (we can list the places where the process failed, but that leaves the user clueless with how to solve the problem anyway). I think this moves the bad experience of "ported software stops working after an upgrade" to "Haiku package manager corrupts configuration files and leaves programs in non-working state". I don't think we can do more than warning the user about a conflict of settings files. For software that really can't handle more than a single settings file, I'd go with a default one in the package (read-only) and let the user copy it to its home directory and modify it if needed. Since we already patch most of the software to use find_directory anyway, I don't see how that would make the porting task significantly more work. As long as the software can handle a way to include a configuration file from another, the user settings can do so and just set the few options the user wants to change. This makes the settings file easier to understand. I think most ported software will allow that. If the format of the file changes completely from a version to another, that solution won't work. But any guesswork the package manager could do to try merging the files is unlikely to do better. -- Adrien.