Explanation of "refresh" vs "install" of a new revision of an installed snap?

In general it seems to me that “refresh” is basically an alias for “update”: if a newer revision of a snap is available, it will be downloaded and applied over the current revision. Whereas, you use “install” when, well, you’re installing a snap that’s not already there.

My question is: If a snap is already installed and a higher revision is downloaded, does $ snap ack snap_rev.assert && snap install snap_rev.snap do exactly the same thing as if I were to run $ snap refresh snap, with the only difference being the source of the file (local vs store) (and assuming that the downloaded revision was the same as the current one in the store)? This seems to be the case to me, but I’d like confirmation before relying on it.

As a test case I tried this with ddgr, initially installed at revision 106.

  • I ran “ack” and “install” on a previously-downloaded edge revision 124 (change #123).
  • I then “downgraded” it by using “install” on the previously-downloaded revision 106 (change #124).
  • I then used “refresh --revision=124” to re-update it to the previously-installed rev 124 (change #125).
  • Lastly, I used “refresh” alone to re-downgrade it to the current stable store version (change #126).

When I compare the details in changes #123 through #126, it seems like the only difference is that when “installing” from a downloaded file (regardless of whether going to a higher or lower revision) a temp file is used to hold the snap during the install. Otherwise, I see all the same steps in the installs and refreshes:

  • Ensure prerequisites for “ddgr” are available
  • Prepare snap “/tmp/snapd-sideload-pkg-780198744” (106) [or Prepare snap “” (106)]
  • Run pre-refresh hook of “ddgr” snap if present
  • Stop snap “ddgr” services
  • Remove aliases for snap “ddgr”
  • Make current revision for snap “ddgr” unavailable
  • Copy snap “ddgr” data
  • Setup snap “ddgr” (106) security profiles
  • Make snap “ddgr” (106) available to the system
  • Automatically connect eligible plugs and slots of snap “ddgr”
  • Set automatic aliases for snap “ddgr”
  • Setup snap “ddgr” aliases
  • Run post-refresh hook of “ddgr” snap if present
  • Start snap “ddgr” (106) services
  • Clean up “ddgr” (106) install
  • Run configure hook of “ddgr” snap if present

Short answer: mostly yes. If some-snap is installed, and there are no snaps installed that gate that snap (you’ll know if that’s you), and the snap epochs are compatible, snap download some-snap && snap ack some-snap_*.assert && snap install ./some-snap_*.snap should result in a change with all the same tasks as a manual snap refresh some-snap, including hooks and such. snap install of a local snap with a name that is already installed is treated as a refresh, and we have tests for this. More importantly for you: if they are different in any substantial way, it’s a bug.

Longer answer: snap refresh might do more things, such as refreshing other assertions, which you won’t get by doing it this way. I’d defer to @pedronis on the details of this.

1 Like