Guidance on usage of "current" in $SNAP_DATA et al

snapd
2

We are aware of this problem (or rather, of this family of problems), and resolving them is the ultimate goal of @zyga-snapd’s Refresh App Awareness work.

In the meantime,

  1. yes, use current in any and all config, rather than the revisioned versions.

  2. it’s not safe, but we’ll be changing them once it is (safe does not imply works-everywhere, as per the corner cases you mention, but there isn’t one that works everywhere and it seems having current in the variables is the least surprising)

  3. snapd doesn’t tell you the last revision (and it’d be tricky to do). You’ve got three options, all on your side right now:

    • use current in the config and then do realpath before using the values,
    • interpolate $SNAP_ variables in your config, or
    • have a configure hook and use it to retrieve the last revision and store the current one

the last one, which involves rewriting the config every revision change, sounds really messy to me but if you can’t change your code per the other two might be your only one. The configure hook doesn’t need to do anything; it’s just there so snapctl set lastrev="$SNAP_REVISION" works (and after you’ve done that, snapctl get lastrev would work).

As long as your apps that write to $SNAP_DATA are daemons, all the above should work without issue today. The real problem is with non-daemon apps which today might be alive straddling a refresh, where their security profiles point to one directory and current (or $SNAP_DATA) would point to another.

1 Like