Channel fallback doesn't change tracked channel

snapd
1

Say I install a snap from a branch:

$ sudo snap install nextcloud --channel=stable/junk
$ snap info nextcloud
name:      nextcloud
summary:   "Nextcloud Server"
publisher: nextcloud
contact:   https://github.com/nextcloud/nextcloud-snap
description: |
  Access & share your files, calendars, contacts, mail & more from any device,
  on your terms.
commands:
  - nextcloud.disable-https
  - nextcloud.enable-https
  - nextcloud.manual-install
  - nextcloud.mysql-client
  - nextcloud.mysqldump
  - nextcloud.occ
tracking:           stable/junk
installed:          latest-stable11 (1498) 184MB -
refreshed:          2017-05-29 01:37:21 +0100 BST
channels:                                  
  latest/stable:    11.0.3snap3     (1474) 186MB -
  latest/candidate: 11.0.3snap3     (1472) 186MB -
  latest/beta:      latest-stable11 (1498) 184MB -
  latest/edge:      latest-master   (1499) 185MB -

And then that branch gets closed:

$ snapcraft close nextcloud stable/junk

Then I snap refresh:

$ sudo snap refresh nextcloud
2017-05-30T16:50:14+01:00 INFO cannot auto connect nextcloud:network-bind to core:network-bind: (plug auto-connection), existing connection state "nextcloud:network-bind core:network-bind" in the way
nextcloud (stable/junk) 11.0.3snap3 from 'nextcloud' refreshed

Note that it actually did refresh to the right revision, but it thinks it came from stable/junk instead of stable. snap info thinks the same:

$ snap info nextcloud
name:      nextcloud
summary:   "Nextcloud Server"
publisher: nextcloud
contact:   https://github.com/nextcloud/nextcloud-snap
description: |
  Access & share your files, calendars, contacts, mail & more from any device,
  on your terms.
commands:
  - nextcloud.disable-https
  - nextcloud.enable-https
  - nextcloud.manual-install
  - nextcloud.mysql-client
  - nextcloud.mysqldump
  - nextcloud.occ
tracking:           stable/junk
installed:          11.0.3snap3 (1474) 186MB -
refreshed:          2017-05-26 20:33:35 +0100 BST
channels:                                  
  latest/stable:    11.0.3snap3     (1474) 186MB -
  latest/candidate: 11.0.3snap3     (1472) 186MB -
  latest/beta:      latest-stable11 (1498) 184MB -
  latest/edge:      latest-master   (1499) 185MB -

Is this by design?

2

Yes, that’s by design. If the system manager explicitly ask for stable/foo, the configuration needs to remain saying stable/foo for as long as that’s desired, and the client needs to request stable/foo to the store, and the store needs to offer stable/foo if it exists or if it ever shows up again, and its fallback otherwise (stable in that case).

This behavior is not special for branches. Every other channel works exactly like that (edge, beta, etc). Without that, it would get awkward in multiple senses:

  • The system manager would see the configuration changing behind their back
  • Flipping the close switch back and forth would destroy everybody’s configuration
  • People wouldn’t be able to follow a beta channel permanently, although they explicitly requested that

and so on.

3

Alright, thanks for the explanation. That makes sense for the standard channels, though it seems a little awkward for something that is hard-coded to be short-lived.