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

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 23 Apr 2013 17:01:40 +0200


I'd like to gather a few opinions and ideas wrt. how we want to handle settings (and similar) files in a package management context. Mainly this is about what shall happen with a software's settings files when said software is installed/uninstalled/updated.

There are a few different kinds of settings files, which may need different handling:

1. Highly compatible settings

Common for native applications. The application can load settings files written by an older (or newer) version. The settings file may be completely optional or a default settings file must or is recommended to be installed.

- Installation/update: No-op, if the software doesn't come with a
  default to be installed or there already is a settings file
  installed. Otherwise install the default.
- Deinstallation: Remove settings file, if desired by the user
  (maybe back up first).

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.

3. Directories

The contents of a directory comprises the settings. Examples are the Deskbar menu, the MIME DB, or Tracker's New templates. The Expander settings -- at least for the defaults -- will also be changed to consist of a file per rule. This will allow packages like xz-utils and p7zip to easily contribute respective expander rules.

The MIME DB will probably be straight-forward. Installed packages can contribute their own types to the MIME DB. Those will be read-only files in system, common, and home/config. Changes made by the user will be stored in home/config/settings and override the more general directories. It will work in a similar way for the Expander rules.

For the Deskbar menu and Tracker's New templates this merge approach doesn't really work, since one would e.g. always end up with all installed applications in the Deskbar menu (plus what the user has put in the respective settings directory). Options to deal with that could be:
a) Never include the Deskbar menu symlinks. The user would always have
   to manually add a newly installed application to the menu.
b) A package could specify for which of its files which Deskbar menu
   entries could be created. The package manager could create those
   (according to a setting) automatically or after asking the user.
c) Like b) just more general: The package file could specify optional
   settings files (in this case symlinks). The user would have to
   acknowledge the installation of those. There could be a setting to
   automatically do that for certain directories.

b) and c) might not work all that well for users with their own organization (e.g. subcategories).

Regarding Tracker's New templates, I'm not sure in which package(s) they will end up (just the system package, the development related ones (C++ header/source file, Makefile) in the development package, or all in a separate "default user settings" package) and whether third-party packages are supposed to contribute further templates. My ideas so far:
a) The templates could just be provided in some public directory and the
   user would have to copy the desired templates to the settings
   directory explicitly.
b) Like a), but if the user's respective settings directory does not
   exist, the default templates would be used.
c) The template files could be handled similarly to 1. above, i.e. on
   installation/update they would be installed, if not there yet. The
   "on update" case might be annoying, though (removed templates
   reappearing on each update), so maybe an additional flag to indicate
   that it should only happen on first installation is needed. The user
   would miss any new templates that come with a Haiku update.
d) The templates and possibly other settings come in a "default user
   settings" package that is copied/extracted to the user's home
   directory when the user's account is created (i.e. on first
   installation until we go multi-user).

Thoughts? Opinions? Ideas?

CU, Ingo

Other related posts: