When inside a snap the $HOME is bent into shape so it actually is $actualhome/snap/$name/$rev instead of the actual user’s home.
At the same time there also exists snap/$name/current which symlinks to the whatever the latest revision is.
Why is $HOME by default the revision’ed version and not current? Or perhaps more to the point: would anything break if I forced it to be current for snap?
Specifically in lots of KDE apps we eventually would write disk paths to configs. For example if the user went to configure the torrent download location in KTorrent, they’d be by default dropped into $HOME/Download (e.g. /home/user/snap/ktorrent/32/Downoad effectively). The problem with that of course is, that once the snap gets updated to revision 33 the paths would be wrong and the application possibly defunct.
The way I see it is there isn’t much to help prevent this. Either $HOME, as far as the application is concerned, is set to /current, or a launch helper attempts to mangle pre-existing configuration data.
The latter of the two would not only be slow, it’d also be fairly unreliable because for example Qt-only software does at times store binary blobs in configs.
having a versioned data dir based on the snap revision is the only way to guarantee the data fully works with the binary of a particular snap revision if you roll back or go forward in revisions, your binary might have changed the syntax of the config, its API to access data, or the format of user stored database data …
to not having to transition back and forth the data when switching back and forth snap revisions, each snap has its own data storage location … if you are sure there are typically no changes you can indeed make your app just use the /current symlink, this is exactly what it is for … or even easier, set your $HOME permanently to $SNAP_USER_COMMON, from a wrapper or (untested) via an environment: entry in the apps section of your snapcraft.yaml.
It does make me wonder though… The problem ultimately is that the actual path of $HOME changes, but does it need to? Couldn’t it simply be /snap-home in-snap, which is bound from the on-host /home/$user/.../23 when inside rev 23 of the snap, and bound to something else when on rev 22.
For the issue I am having it’d be perfectly fine to have isolated homes per revision, but the application need not know about it. As far as the app is concerned the fact that the snap’s home location on-disk changed isn’t useful. 23/ gets pre-seeded with 22/'s content. When upgrading, 23’s home initially looks like 22’s home. Upon rollback 22’s home looks like it always did as it never changed. But the fact that they are different directories on-disk is an implementation detail which doesn’t matter when I’m inside a confined snap.
Yeah, at some point we’re going to change it to point to .../current/ directly. However when we tried to do that it broke things in rather interesting corner cases, so we had to step back and rethink.
