@degville With snapd 2.57 a new variable has been introduced on ubuntu core systems.
SNAP_SAVE_DATA
Points to a snap-specific location on the ubuntu-save partition where the snap is allowed to store persistent files (like certificates or configuration files) which will survive a factory reset. The variable is only exposed on Ubuntu Core systems, and was introduced with snapd 2.57
I would like to improve the description of this environment variable as per Where to store config files but I canât figure out the proper words, please help fix it.
This directory is suitable to store potentially backward-incompatible data as the data is backed up and restored across snap refresh and snap revert operations so the users can restore the application to its previous state even if the data breaks its newly released revisions.
I believe this part is incorrect as snapd only guarantees that if data incompatibility issues occur you can rollback to the previous working unmodified data and software(to the extent that the previous data hasnât dropped by the rotation logic).
When a snap is refreshed the SNAP_USER_DATA of the previous snap revision gets duplicated to the new revision, not cleared.
The âThis makes sure the older version of your application doesnât use newer, backwards-incompatible, data.â part seems to be ambiguous IMO, how about the following instead:
I think it could be useful if the parts of this doc regarding data storage would be in a dedicated documentation (maybe linked here).
Newcomers to snapcraft might not understand where they can and cannot store data on with their snap.
I believe a doc similar to the android one would help.
Thanks - and thatâs a good idea. In particular, Iâve been having discussions about SNAP_USER_COMMON and snapshots - whatâs stored against a specific revision. So, we do need to revisit this, and splitting out data storage makes sense.
Itâd be nice to have a SNAP_BASE variable with the name of the base snap used.
The LXD team maintains 3 tracks (4.0, 5.0 and latest) and each of those depend on a different base snap (core2x). Since we have scripts needing to know which base is used, having that variable would make it easier to backport changes between those tracks.
Our current approach is to dynamically look that up like that:
# Detect base name
SNAP_BASE="$(sed -n '/^name:/ s/^name:\s*\(core[0-9]\{2\}\)/\1/p' /meta/snap.yaml)"