Snap refresh not working as expected on devmode snaps

[Greg Lutostanski]

So yesterday I installed the juju snap...

$ sudo snap install juju --edge --devmode

then today... https://paste.ubuntu.com/24002666/

Does snap refresh just not work on devmode snaps, what is going on here? And why are they not auto-downloaded.

lutostag@cia:~$ snap --version
snap 2.21+16.10
snapd 2.21+16.10
series 16
ubuntu 16.10

Let me know if I can provide anything else.

P.S. it works if I manually $ snap install juju --edge --devmode #again

[Pat McGowan (pat-mcgowan)]

With devmode you always need to use the option:
$ snap refresh juju --devmode
and they are not auto-updated

[Joshua Bayfield (jbayfield)]

Marking as invalid according to Pat McGowan's comment.

[Greg Lutostanski (lutostag)]

Thanks for quick reply. Documentation is ambiguous on this point and therefore confused me.

Filed a bug @ https://github.com/ubuntudesign/snapcraft.io/issues/281

Appreciate the awesomeness that is snap*!

[Mark Shuttleworth (sabdfl)]

Hmm... my understanding of the intent was different.

You should get updates from devmode to devmode, and from devmode to
strict (safer), but you should not auto-update from strict to devmode or
classic.

I think it's a bug if that's not the current behavior, unless one of the
snapd core devs explains otherwise.

Mark

[Pat McGowan (pat-mcgowan)]

reopening to get some confirmation

[Gustavo Niemeyer (niemeyer)]

The current behavior was the precise outcome of a very long conversation we (Mark and I) had in Heidelberg, about the subtle properties of such updates. We agreed to block devmode => strict refreshes because we could not get a clear agreement on what was the proper way to treat those updates. Specifically, on refreshes that go from a snap that proposes devmode to one that proposes strict should it:

1. Refresh and keep the devmode flag on

or

2. Refresh and disable the devmode flag

I believe the more natural semantic is (1), given the flag meaning (development mode), while Mark would like to have behavior (2), taking the flag off. Behavior (2) doesn't seem sensible to me because it's an automatic and transparent change behind the developer's back which is changing the behavior of said snap for no apparent reason. It would also cause the strange effect that a devmode snap can be updated to strict, but cannot be updated _through_ strict (devmode => strict => devmode), even though the developer explicitly said this snap was in development mode before.

So, if we go with 1, sounds good to me. If the idea is 2, then I'd prefer to keep the current behavior as we originally discussed in Heidelberg.

[Greg Lutostanski (lutostag)]

Thanks for the well thought out explanation.

I would proffer and alternative until either #1 or #2 can be decided upon.

Refresh for all snaps that stay in the same confinement mode. I.e. one --devmode snap to a more recent --devmode snap, which currently does not happen.

I agree that upgrades across confinement modes are more tricky and the right decision must be made, I think the snap team can come up with the correct approach for that in the longer term.

[Mark Shuttleworth (sabdfl)]

Ha! Of course I only remember my side of the discussion :)

Gustavo, are you suggesting that the snap would be refreshed and STAY in
devmode? Or that it would switch to strict (remember the possiblity of
devmode), and go to devmode if a subsequent revision specified devmode,
with no prompt?

I would be more comfortable with it staying in devmode through those
changes, if we show devmode nicely in the 'snap list' output.

Mark

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Pat McGowan (pat-mcgowan)]

it is also the case that snap refresh --list does not show new updates on the devmode snaps, which is consistent I suppose, but if it did show them one could know to manually do the refresh.