Preserve configuration file in addon directory during updates

[herrfrei]

Hello Kevin,

I have written the SetupHelper scripts for https://github.com/henne49/dbus-opendtu and now have a problem with the addon's configuration file.

• Originally it is located in the addon directory. After the last update I found out that SH replaces the whole directory without keeping some files.
• My idea was to move the configuration file to /data/conf, which looks fine to me. And it should work.
• Now, a user in my PR (Configuration settable from outside henne49/dbus-opendtu#157) mentioned that he is using two instances of the addon for different hardware modules and he needs to store the config files in the addon directories. I assume his case would not work easily with SH, but I don't want to have two different implementations of the configuration reading code (at the moment I have modified the main file for SH usage, see dbus-opendtu-sh.py.

How can we solve this problem?

[kwindrem]

Yes, the entire package directory is replaced when downloading a package.

I have provided a place to store config files, etc for each package: /data/setupOptions/ that will survive a firmware update or package download.

Actually any location in /data will survive a firmware update. /data/conf is where Victron stores its configuration information and persistent storage for settings. That might not be a good location as this is the folder that will likely be replaced or heavily modified when doing a configuration backup/restore (planned for the future).

[herrfrei]

The problem is that the mentioned package may be installed multiple times in different directories (without SetupHelper, of course). Then the /data/setupOptions approach does not work. That's why I 'd like to have a call to setup in the old package directory before removing the package (to preserve files, e.g. in /tmp). During installation of the new package I'll add a check if a configuration is already available and move this back to the new package directory.

[kwindrem]

You should be able to call setup from the "old" package from setup in the "new" package. The setup script can make copies of whatever files you need to retain as part of the uninstall portion.

[herrfrei]

Do you have some hints for me how to do that? Are both the old and new package available during installation of the new one? What are are the directory names if both exist?

[kwindrem]

When a package downloads from GitHub, it replaces the copy in /data. The "old" package contents are lost. The same name is used before and after the download.

You could have your script make a backup copy of the package's directory: /data/.backup during an install, then calling the setup script in .backup directory with the uninstall option prior to installing the new version.

SetupHelper provides no support for a package being installed multiple times unless they have unique names: Foo_1, Foo_2, etc. In this case the setupOptions would also have unique names.

[herrfrei]

I see. So I need to adjust the packages' services to backup the settings (on every start).

I thought we could call the old package's setup with a new command (e.g. BACKUP_SETTINGS) before deleting the package when updating. Then I wouldn't need to adjust the original packages (without SetupHelper).

Another idea: Is it possible to add second service to a package to backup the settings? This service should only run once at startup and stop right after the backup is finished.

[kwindrem]

Settings are not overwritten as part of a package download or install. It's only the contents of the package directory itself. If you store your settings in setupOptions or any other location in /data they will survive a firmware update or package download (or update from removable media).

If you are not using SetupHelper to manage your package then you are totally free to do what you want.