[haiku-development] Re: RFC: Package management and handling of settings files

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 23 Apr 2013 19:44:47 +0200

On 04/23/2013 06:04 PM, pulkomandy@xxxxxxxxxxxxx wrote:

On 2013-04-23 at 17:01:40 [+0200], Ingo Weinhold <ingo_weinhold@xxxxxx>
2. Potentially incompatible settings

Not unheard of in ported software. Some kind of configuration file is
required and the format respectively the default configuration changes.
The package format could allow marking the file as "mergeable" for
simple text formats, in which case an attempt could be made to merge
changes made by the user with those introduced by the newer version.

- Installation: If settings file is not installed, install it.
    Otherwise don't touch it.
- Update: If not modified by the user, just replace the installed file.
    If modified by the user and marked "mergeable", try merging. In either
    case back up the old default version and, if modified, also the
    user-modified version.
- Deinstallation: Remove, if desired; maybe back up.

If the old settings file could not be replaced/merged, the package
manager could issue a warning. The software may not run correctly --
hopefully complaining about the configuration file on start-up. The user
will have to fix the situation manually. Having backed-up versions of
the old files will be helpful in such a case.

 From my experience using Debian, this often doesn't work well. When the
merge fails (and it usually does), you're left with options of losing your
configuration, or risking to break something that was working. The other
option is trying to understand what's going on and try to merge stuff
yourself. As times goes, your custom config drifts away from the expected
format and becomes less and less easy to merge.

I would have expected that most changes are just additions of new values or sections and should merge smoothly. My suggestion was not to let the package manager do anything "intelligent" in a case where it just doesn't have enough information. The idea is to try to help the user keep things in sync by assisting with the simple cases that would just be menial work. Just to be clear on this:

* Mergeability would need to be flagged explicitly by the port/packager. There's no point in even trying with more complex file formats (like XML).

* Merging should only happen when confirmed by the user. A setting to do that automatically is probably nice. There should also be a setting to disable merging altogether. In either case the necessity/success/failure of the merging should be displayed to avoid surprises.

I'd not even try to support this at the package manager side. This is a
problem it can't solve. There are, on the other hand, valid solutions for
most software :

  - Modifying software to understand older versions of the settings file.
Problem solved.
  - Using a multi-file configuration. The default settings go in a read-only
directory, and the user can create a custom setting file in the user
settings dir, with only the settings he wants to override. This way, there
is nothing to merge, new options are added to the read-only file with
default values, and user customizations are kept.

Adjusting all software to be perfect is always an option. Unfortunately also a not particularly realistic one. We should certainly try to make our native software deal gracefully with older settings files, but unless we find a bunch of full-time maintainers for our ported software, that solution isn't generally applicable.

CU, Ingo

Other related posts: