Why do devmode snaps not auto update?

[popey]

Install a devmode edge channel snap from the store (such as peek). The developer is actively working on the snap and as such is revving the snap frequently. Typically we talk to developers and users about snaps being kept up to date automatically in the background. So they know they’ll get the latest version of the edge devmode snap when the developer pushes.

However, that doesn’t work for devmode snaps:-

Here is one I installed some time ago:-

Name  Version    Rev  Developer  Notes
peek  1.0.1+git  60   phw        devmode

I am tracking edge:-

alan@gort:~$ snap info peek
name:      peek
summary:   "Simple animated GIF screen recorder with an easy to use interface"
publisher: phw
contact:   https://github.com/phw/peek/issues
description: |
  Peek creates animated GIF screencasts using FFmpeg and ImageMagick. It was
  built for the specific use case of recording screen areas, e.g., for easily
  showing UI features of your own apps or for showing a bug in bug reports. It
  is not a general purpose screencast app with extended features and it never
  will be.
  
commands:
  - peek
tracking:      edge
installed:     1.0.1+git (60) 71MB devmode
refreshed:     2017-04-06 10:40:38 +0100 BST
channels:                      
  latest/edge: 1.0.3+git (165) 71MB devmode

Force a refresh of all snaps:-

alan@gort:~$ snap refresh
All snaps up to date.

Force refresh of that one snap:-

alan@gort:~$ snap refresh peek
error: snap "peek" requires devmode or confinement override
alan@gort:~$ snap refresh peek --devmode
2017-06-16T08:47:06+01:00 INFO cannot auto connect peek:x11 to core:x11: (plug auto-connection), existing connection state "peek:x11 core:x11" in the way
peek (edge) 1.0.3+git from 'phw' refreshed

Why?

[popey]

@niemeyer ^ is this desired behaviour or a bug?

[niemeyer]

The current behavior was the outcome of a discussion we had in the Heidelberg sprint, about the subtle properties of such updates. The main issue is actually the devmode → strict refreshes, and 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
2. Refresh and disable the devmode flag

I believe the more natural semantic is (1), given the flag meaning (development mode), while another stakeholder 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 modifying 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 we ended up blocking these updates as a compromise and as a way to learn more.

[evan]

I think you’re likely to start in devmode and share it around after you get it basically working and before any time is given to strictly confining it. So I understand the motivation for (2). You want to upgrade these early adopters to strict confinement. They probably installed with --devmode because you told them to.

[niemeyer]

The –devmode flag means development mode. It doesn’t make sense to upgrade someone out of a developer experience. The developer gets out of it when and if they want to stop working on the snap, and if we recommend someone to install things in that mode, we’re asking them to also get on board of that developer experience which entails extra debugging messages, unconfined access that warns about access violations but that can really do anything in the system, and so on.

This is not the typical “hey, try out this beta version”. For that, confine the application properly first, or release a classic snap if it’s impossible to confine it for the case at hand.

[Ads20000]

Thinking long-term, isn’t it best to avoid classic confinement where possible so that snaps can work on Ubuntu Core (I’m assuming Ubuntu wants to move to being snap-based rather than Deb-based in the very long-term), also so they don’t need manual review?

Alternatively we give this up, assume that bugs like the ones in the Peek Devmode snap are unfixable, and recommend classic confinement much more than we are at the moment!

[niemeyer]

Yes, the final goal is still to have everything confined, and classic rendered obsolete. The point above was not suggesting otherwise, but rather saying that classic is today a viable alternative if people can’t confine their snaps properly yet but want to do non-development releases.

[denis]

Refresh and keep the devmode flag on

This is the only reasonable option.

I hope this is available as soon is possible. Is there any timeframe for the decision?

You may have multiple test units and update all of them by hands is nonsense. And I’ve already felt this burden. I can’t imagine who may want an option 2 and why. If someone feels uncomfortable with devmode, he shouldn’t use it.

[niemeyer]

I’ll add a topic to the sprint next week.

[denis]

Hi, @niemeyer, will it be integrated in snapd 2.27 ?

[niemeyer]

This won’t be on 2.27, but we have agreement on the actual changes from the sprint. We just need a moment to sit down and implement now. I’m tagging this as upcoming so we don’t forget.

This is the photo from the whiteboard taken after the sprint conversation:

Development sprint June 26th, 2017

Agreements about the devmode refresh behavior: [image]