Unexpected revision information exposed in some situations

In order to get the “channel map”, that is, snapd hits the store with channel set to the empty string (without that the channel map returned would be filtered to only show the requested channel, which defaults to latest/stable).

In this situation the metadata outside of the returned channel map is about the most recent revision that is in the channel map. This is unexpected client-side, but we hadn’t noticed before because the snap client just exposed the metadata from the channel map, and gnome-software (or is it snapd-glib?) didn’t expose the information and (afaict) just used what search returned.

So, the store is exposing unexpected revision information, and snapd and then (snapd-glib and) gnome-software is presenting it to the user.

One possible fix would be to change the store behaviour to always return latest/stable if that channel is open, when querying with channel="". The question is whether this behaviour change will break anybody’s workflow, as it’s a behaviour change. I think it shouldn’t, but we can’t really know.

Another would be for snapd to query the store twice, once with channel=stable and once with the empty string.

A workaround would be for gnome software to use the info from the channel map instead of from outside, but it’s possible there’s info gnome software needs that is per revision and isn’t in the current map.


1 Like

This was one of the questions I had when the channels were introduced - what do we do with the snapd fields that existed before.

I think the logical thing for the “legacy” version field is it should show the version that would be installed if you installed without any other parameters set. So in most cases, the version from “latest/stable”. So +1 on making that change from my perspective (I don’t consider it a break, but a bug fix).

In terms of GNOME Software today - we change the version label to the value from that channel map when you select a channel - we should just do that the first time the snap is shown to give correct information. It’s not clear though if that now means we can completely ignore the version field now and just rely on a channel map existing.

I fixed the bug in GNOME Software by using the channel map when we have one, and falling back to the “version” field when we don’t.

1 Like

Note this is being tracked in bug 1767445.

(eugh, sorry this was sitting in draft for > 1 week!)