no it can’t, because $XDG_CONFIG_HOME is set by the user, per-user, at runtime.
Oh I see, but as a partial workaround can it be something like this?
plugs:
personal-files:
write: [ $HOME/.config/gwe ]
read: [ $HOME/.config/gwe ]
Can I then force the $XDG_CONFIG_HOME of my Snap to be $HOME/.config (currently it points to $HOME/snap/gwe/x1/.config/)? If yes, how?
If the folder $HOME/.config/gwe does not exist already, can it be a problem? Am I allowed to create it from my snap? Would a normal mkdir -p $HOME/.config/gwe work from inside the snap?
Yes. But why do you want this? Why not use the .config inside $SNAP_USER_DATA?
As said in #17, the use case is allowing the user to switch freely and smoothly from and to Snap.
Possible use cases are:
- I install GWE from Flathub, I create my custom fan profiles, I uninstall Flatpak GWE and install Snap Store GWE, I still have my profiles.
- I install GWE from Snap Store, I create my custom fan profiles, I uninstall GWE, I reinstall GWE, I still have my profiles (maybe this is already covered by
$SNAP_USER_DATA)
And other combinations using different package managers and sources for the app.
Then imagine you made (intentionally or not) backward incompatible change in app config. Now switching between different app installation sources could make shared configs broken (snaps even make effort to keep separate config for each app version).
This also breaks sandboxing guarantee as normally app can’t access other apps configs in snap/flatpak if they’re stored in designated directory but not if you set it up like you want.
Please don’t mix host & snap & flatpak configs.
@Reynolds5 I understand your POV but I still believe that it should be possible to do it if a developer want to take the challenge of maintaining backward compatibility for his $XDG_CONFIG_HOME.
Just to clarify: I don’t want this behavior to be changed for all the apps, I just want to be able to use it if needed.
That would break my app because it relies on creating profiles and keeping them between app upgrades.
To be clear, if you put data/config files in $SNAP_DATA (or $SNAP_USER_DATA) that is per-revision and any files put there will disappear and need to be repopulated on snap upgrade. However these files do get backed up on an upgrade so if the upgrade goes awry, you can revert (or in some cases the snap will be auto-reverted) to the old revision and the files will be re-populated. If you use $SNAP_COMMON (or $SNAP_USER_COMMON) however, these files will not be modified on snap upgrade. This also means you don’t get any backup of the files in $SNAP_COMMON.
sorry, but that’s absolutely not true. The directories are per revision, but they get get backed up / copied forward (depending on the version of snapd) on upgrade; it’ll be there.
1 Like
To be clear, I may have used the phrase “disappeared” a little heavily, what I meant is that the current revision of the snap after an upgrade will not see the same files as the previous revision did because $SNAP_DATA points to a new directory.
I was aware of the backing up feature on a revert, I was not aware of the “copied forward” feature, what version of snapd was that added to? And does the “copied forward” feature apply to automatic refreshes only?
it’s been there since before it was called snapd. And no, any refresh behaves the same way wrt the data.
2 posts were merged into an existing topic: Clj-kondo linter classic snap