On 03/14/2012 10:10 AM, Benoît Burnichon wrote:
To avoid loss of configuration when upgrading packages with default
configurations.
This is a tricky subject. On some embedded systems it may be expected
for a user or configuration utility to change some configs while not
other configs. On some embedded systems it may be impossible (or
unlikely) for the user to modify configurations.
When a package is upgraded sometimes new configuration options are added
and sometimes they are deleted, sometimes the format of the
configuration is changed entirely or moved to a different location.
Other times the upgrade is just a maintenance release and only contains
minor fixes.
If you mark a file as a config file by default opkg won't upgrade that
file during a package upgrade, even if the user never made any
modifications. At this point you are basically deciding to leave the
original file unchanged and putting the burden of merging old and new
config files on the user.
We've dealt with this by leaving install_alternative for all config
files by default and only making custom rules with install_config for
files we intend for users to change. For our device it makes sense for
instance that a user may want to modify ntp.conf to add an ntp time
source (we provide a web based utility to do this), yet it makes no
sense for a user to change the dbus configuration. If during the course
of a version upgrade a configuration option is renamed, eliminated or
added, we provide a .postinstall script to modify the user configuration
and make the required changes so the user doesn't end up with a broken
device.
Ultimately I think a better frame work is needed to handle management of
configs. Suppose your user wants to backup his device's configuration
files to a PC. Then suppose said user's device is burnt to a crisp when
lightning strikes an improperly arrested antenna (this has happened). He
orders replacement but it arrives with new firmware. He sends his backed
up config files to it from a and it doesn't work because the name of a
setting in one of the config files changed.
Ideally you could provide a single script to migrate a config file from
one package version to another. This script could be used when the
package is upgraded OR when users send configuration files to the device.
Regards,
George McCollister
--
ptxdist mailing list
[email protected]
