Differences between revisions 3 and 4
Revision 3 as of 2009-03-23 13:01:37
Size: 2801
Comment: Fixed links
Revision 4 as of 2009-03-24 16:25:19
Size: 4029
Comment: Added summary of Config::Model
Deletions are marked like this. Additions are marked like this.
Line 29: Line 29:
short summary of config::Model (link) [[http://freshmeat.net/projects/config_model|Config-Model]] provides a framework for editing and validating the content of any configuration file or data. With a configuration model (expressed in a data structure), Config-Model provides a user interface and a tool to validate configuration.

The configuration model contains the following specifications:
 * the structure of the configuration model. This structure can be flat (`approx.conf`) or tree-like (like `xorg.conf`)
 * the constraints of the leaf values (i.e. integer, enum type, min values, max values ...)
 * the default values where the default value '''must''' be written in the configuration file.
 * the ''built-in'' default value where the value need not be written in the configuration file. This default value is ''built in'' the application.

This notion of default value versus built-in default value is important to distinguish:
 1. the values that were customized by the user (or sysadmin)
 1. the value that are recommended by the package maintainer (and specified as `default` in the model)
 1. the value that are built in the application.

During an upgrade we want to propagate only the customized values from the old configuration file to the upgraded configuration file.

Translation(s): none

(!) ?Discussion


This page contains a proposal for a way to handle upgrade where user's data and package maintainer data are merged with minimal interaction with user. The package approx will be used as an example.

Configuration upgrade by package

Status

This page is a proposal. It is not (yet?) accepted by Debian project. Stay tuned.

Introduction

For a casual user, the questions asked during package upgrades can be intimidating. Often, the user is faces with cryptic questions whether to keep his configuration, use the maintainers configuration or look at a diff. The casual user will seldom know what to do in this case.

This situation can be made worse if user's configuration was edited with a tool (e.g. cups configuration is edited through a web browser): the user has no knowledge of the syntax of the configuration file.

This proposal aims to provide a way for Debian package to minimize the number of questions raised to the user when upgrading packages. If questions are necessary, an interface will be provided to the user so that manual edition of configuration files will not be necessary.

Upgrades with Config::Model

Config-Model provides a framework for editing and validating the content of any configuration file or data. With a configuration model (expressed in a data structure), Config-Model provides a user interface and a tool to validate configuration.

The configuration model contains the following specifications:

  • the structure of the configuration model. This structure can be flat (approx.conf) or tree-like (like xorg.conf)

  • the constraints of the leaf values (i.e. integer, enum type, min values, max values ...)
  • the default values where the default value must be written in the configuration file.

  • the built-in default value where the value need not be written in the configuration file. This default value is built in the application.

This notion of default value versus built-in default value is important to distinguish:

  1. the values that were customized by the user (or sysadmin)
  2. the value that are recommended by the package maintainer (and specified as default in the model)

  3. the value that are built in the application.

During an upgrade we want to propagate only the customized values from the old configuration file to the upgraded configuration file.

how does the upgrade work (dump of custom values with 'old' model, load custom values with 'new' model)

Alternatives

ucf, 3-way diff

Approx example

configuration analysis

What kind of config paramters, config structure. What's the syntax ? Can it be read with Augeas ?

Approx configuration model

How to create , integration with reader/writer

Commands to manage upgrade

config-edit in dump mode, config-edit in load mode

Integrate upgrade command in package scripts

dump command in pre-uninstall , load user's data in post-install

What if Approx model is provided in a separate package (i.e. not in approx but in libconfig-model-approx-perl) ?

Fallback in case of upgrade failure

Fallback on ucf as usual.. Other ?



CategoryDebianDevelopment