Behavior change: risk-only channel specifications will not switch track!

snapd
1

We are planning to change the behavior of refresh/switch operations when a risk and only a risk (edge,beta,candidate,stable) is specified, to only change the risk but keep what is the current track of the installation of the snap.

This means for example if a snap is tracking 2.0/stable, snap refresh --candidate SNAP would refresh and switch to using 2.0/candidate. (Now it would jump to latest/candidate).

The context of this is the coming introduction of default tracks and is a generalization of what was done for model-pinned tracks and hinted there.

Reasoning

The tracks of a snap should represent established development trails of its software with a smooth upgrade story within them. Changing the track for an already existing install should be an explicit decision/operation.

So far a snap can have a set of optional tracks and a latest track which represents a rolling development trail. We are working introducing the concept of a default track for a snap, a pointer to one of those tracks, that would typically represent what is currently recommended when starting with a fresh install. The default track would change over time, but preexisting installs would not follow on a change. A snap with a default track might not have a latest track at all.

An install specifying --edge|--beta|--candidate|--stable would use the default track if that is set, whereas this asks for latest/RISK now.

This opens the question of what refresh/switch operations should do in this new world when only a risk is specified. At the moment they ask for a jump all the way to latest/RISK. Historically these options existed before the introduction of tracks at all, given that as we remarked changing track for an existing install should be a very conscious/explicit decision we wonder if keeping that behavior is sensible within the now much richer world of tracks and default tracks, and think it is appropriate to consider moving to a safer behavior where they switch only the risk keeping the current track.

Specifying a full channel with a track would still allow to switch track, and we would also introduce a default alias to refer to the current default track. Also for a snap with only a latest track the behavior would also continue to be the same.

We are interested in feedback about this planned behavior change.

10 Likes
2
3

This was discussed today about how it would affect snapd-glib and graphical clients (e.g. GNOME Software).

The snapd-glib API reflects the information as provided by snapd, so changes to track names and behaviours will not break anything there.

GNOME Software provide the user with the available channels to use, and the user then decides which one to select. I would expect other graphical clients to do the same thing. So the user might be presented with slightly different choices, but as long as they understand the meaning of channels they should still be able to effectively use them.

snapcraft.io seems to use full names for channels rather than abbreviations. GNOME Software currently uses the abbreviations but I think it should switch to full names to avoid any confusion here. There’s no need for abbreviations here as they’re selected with a mouse pointer, not typed in via keyboard.

4

This behavior change has landed in:

and will be in 2.41.

5

and a small followup to include latest/ in channel names of v2/find API call:

1 Like
6

@pedronis / @pstolowski does this change also affect the “channel” property of a snap from /v2/find and “tracking-channel” from /v2/snaps?

i.e.

{
  "name": "skype",
  "channel": "latest/stable", // Does this match the below?
  "channels": {
    "latest/stable": {
      "channel": "latest/stable" // Does this match the above?
    }
}

Asking as we just use a strcmp to decide which channel is the default and to check which channel is installed (using “tracking-channel” from /v2/snaps).

7

Thanks for asking that @robert.ancell, so…

With /v2/find?name=.. the top “channel” attribute (under “name” in your snippet) comes unaltered from the store so no, it doesn’t match those from channels map :frowning:

With /v2/snaps “tracking-channel” we have another problem I think, it reflects the tracking-channel name stored in snapd state, if you installed a snap with old snapd it will just say “stable”.

@chipaca and @ijohnson are working on some fixes concerning migration of old state, I’ll discuss with them.

Thanks

1 Like
8

We are reverting for 2.41 the changes mentioned here so far. The original change is still conceptually sound but it revealed some corner case behavior that we need to deal with, in practice it means snapd will start parsing soon channel input to operations much more and report malformed channels.

https://github.com/snapcore/snapd/pull/7255 alone is not consistent and would need further work. In general snapd API will need to switch to return full channel specs in all cases, because of the larger ambiguity of risk only specifications vs default tracks.

9

I cleaned up version of this landed together with support for default tracks in 2.44.