[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
Greetings,
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.
Handling:
- 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.
Handling:
- 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:
