snap install --revision tracks stable by default

Bug #1679210 reported by Greg Lutostanski
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
snapd
Confirmed
Medium
Unassigned

Bug Description

When I specifically install a revision for testing I would like to keep that revision until I want to switch it. I can't pin to that revision as the next refresh will pull from stable.

Example:
$ snap install etcd --revision=48
$ snap info etcd
name: etcd
summary: "Resilient key-value store by CoreOS"
publisher: canonical
contact: <email address hidden>
description: |
  Etcd is a high availability key-value store, implementing the RAFT
  algorithm to deal with failover within the etcd cluster. Popular
  in the Docker community as a shared store of small but important
  data in a distributed application.

commands:
  - etcd.etcdctl (etcdctl)
tracking: stable
installed: 3.1+master (48) 10MB -
refreshed: 2017-04-01 13:54:44 -0500 CDT
channels:
  stable: 3.1.3 (41) 7MB -
  candidate: 3.1.5 (46) 7MB -
  beta: 3.1.5 (46) 7MB -
  edge: 3.1+master (48) 10MB -

Where it shows "tracking: stable" I specifically do not want to track stable at all, and on a snap refresh it will go to the latest stable without intervention. This is not what I would expect.

Is there a way to pin without refreshing from a channel? (I would expect revision to do this if no channel is given on the commandline).

Revision history for this message
Zygmunt Krynicki (zyga) wrote :

I don't believe there is a way to do what you want right now. There's no way to not follow any channel or any track in the store.

I'm marking this as confirmed / medium for further analysis in another pass.

affects: snappy → snapd
Changed in snapd:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Andrew Scribner (ca-scribner) wrote :

I recently ran into this. Used `snap install microk8s --revision 4891` to install a specific revision from the 1.24/edge channel, but a few hours later I was updated to a revision from a different channel. Now that I know this happened, I know I could have used `snap refresh hold` to hold the refresh, but the default behaviour here feels out of place. Perhaps installing to a revision should by default hold refreshing?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.