Download and prepare-image passing through channel=""

We noticed that when leaving channel unspecified on the command line “snap download” and “snap prepare-image” will pass “” as the channel to the store, which atm will pick the highest revision in that case (a behavior to rediscuss).

  • As a first step we want in all cases snapd to default to channel=“stable” if nothing was specified.
  • As a 2nd step we want an some kind of Ensure fixup for store-bound snaps with Channel in their SnapState set to “”.

So the behavior for channel="" is used by “snap info”


to address this

@noise @natalia We need to drop this behavior soonish, making “” and “stable” mean the same thing. Main concern there is the idea of “highest revision” being exposed. We don’t really want the revision number to be meaningful in any way to the client, other than being a unique identifier.

@niemeyer well I rediscovered with @chipaca that “snap info” depends on that behavior/feature to work at all

Do you have more details? Per above note, largest revision is not something we want to expose anywhere, including (and perhaps most importantly) snap info.

@niemeyer well “snap info” uses it to ask for any revision (it doesn’t care about the channel or precise revision but it want’s to see non stable revisions if that’s all there is)

snap info doesn’t care about “latest” revision; it just needs to be able to ask for something. As such, it could work by asking for ‘edge’, as that will always get something. Right?

@chipaca possibly, it’s a bit unclear what we want, do we want the description from edge or stable if both exists?

I’m not sure the current behavior is super sensible, switching to edge doesn’t seem obviously so either

the description from the store is not tied to a channel though

Having channel as “” and passing a revision explicitly for telling the basic details of a given snap revision would not actually be a concern. The concern would be to have channel empty and no revision and automatically get the latest one, as that’s leaking information which probably shouldn’t be exposed, and also the fact we’re not supposed to hand off access to particular downloads unless they are out of a channel tip or a refresh control assertion (the latter issue was discussed here).

are you saying that with channel="", we’re getting a revision that is not the tip of a channel?

That’s what the top post says, at least.

I just checked and AFAICT it only exposes things that are published to a channel. E.g. sudo has revision 4, but not published to any channel, and the revision does not appear in search results when specifying channel="".

Still, if there are multiple revisions published into multiple channels, it shouldn’t just pick the largest one.

We should either reject the call, or return the one from stable if that’s available. Not an arbitrary one.

we want snap info to work for things that don’t have a revision in stable. I think asking explicitly for edge should work for this though.

That would mean asking for an explicit revision, right? That can continue to work fine.

It doesn’t seem sensible to ask for something in edge unless we really care about edge specifically.

no? where would snap info get an explicit revision from?

Is it the case where the particular snap being consulted isn’t installed in the system? That would mean there’s indeed no revision locally at this point, so we’ll need to ask for a hand from the store to decide what to show.

The sensible thing in this case is probably to return the revision that is in the most stable open channel in the latest track.

If there is an installed revision, then we do have a revision at hand and that’s the revision we should use.

Moving this to the #store category as the conversation is pretty much entirely about it.