classic mode (v1)

[Michael Vogt]

Hello,

I am working on the snappy classic mode. The idea is that you can do:

  $ sudo snappy install ubuntu-classc

and that will install a ubuntu classic environment that has all the
tools like apt/dpkg that people are used to.

Once that is installed you can use it like this :

  $ snappy shell classic
  (classic)$ sudo apt update
  ...
  (classic)$ sudo apt install vim

and have a persistent environment that bind mounts your snappy $HOME
so that you can e.g. build snaps in there.

I am working on a version 1 of this feature right now and made some
good progress (v1 will not implementing everything from the spec, most
notably the delta mechanism is not there yet).

However there is one question I'm keen to get some feedback on:

We implement the classic mode as a writable overlay. The overlay data
is recorded in the $SNAP_APP_DATA_DIR. This means when the user
install "vim" a new /var/lib/dpkg/status file is written to the
$SNAPP_APP_DATA_DIR. This raises the question what will happen when
the underlying ubuntu-classic snap is updated and has new packages in
/var/lib/dpkg/status. We would have to merge /v/l/dpkg/status to make
this work. Same for /etc/passwd and pretty much any file that is in
the ubuntu-classic environment.

It seems like we have the following options:

1) Once ubuntu-classic is installed the snap can never be updated, but
   the *content* of the snap can be updated, i.e. you can keep your
   classic environment up-to-date via "sudo apt full-upgrade" (or we
   could even do it automatically via unattended-upgrades).
   Feels like a real ubuntu system, but also feels strange that a snap
   can not be updated. Workaround would be snappy remove
   ubuntu-classic snappy purge ubuntu-classic and snappy install
   ubuntu-classic to get a new version of the snap itself.

2) All system level changes (like additionally installed packages in
   ubuntu-classic) are lost on each snap update. To make this less of
   an issue we could add meta-data to the snap that stops automatic
   updates and on a manual update we could warn the user that the
   upgrade would mean that the customizations need to be re-done.
   Upside is that it feels much more naturally. Downside is that some
   customization like installing a complex build environment can be
   expensive and not even automated (i.e. people might have copied
   build binaries in there by hand).

3) All system level changes are not persistent and you get a fresh
   overlay each time snappy shell ubuntu-classic is run.

What do you think is the best approach here? Or do I miss something we
could also do?

Thanks,
 Michael

[Thanks to Gustavo for the initial discussion about this!]