classic mode (v1)

John Lenton john.lenton at
Mon Nov 23 17:03:24 UTC 2015

fwiw, “classic.reset” would be afaict indistinguishable from

sudo snappy purge --installed ubuntu-classic

On 23 November 2015 at 16:56, Mark Shuttleworth <mark at> wrote:
> I think we discussed that the two environments would inevitably drift
> (classic falls behind if you are not doing apt-get update in there).
> We also discussed that you might have a "reset" command, which gives you
> a fresh (and entirely up to date) classic dimension. Something like
> classic.reset.
> I don't think we want to use an overlay-on-snap-content because, as you
> say, problems. Rather we want to *construct* the classic environment as
> efficiently as possible, but treat it as a one-time exercise until the
> reset.
> For now, we want the classic environment to persist between shell
> invocations (so you can make it comfortable and reuse it). We don't
> worry about things like daemons starting in the background, all
> processes from the classic dimension can terminate when you exit the
> classic shell.
> Mark
> On 23/11/15 16:48, Michael Vogt wrote:
>> 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?
> --
> snappy-devel mailing list
> snappy-devel at
> Modify settings or unsubscribe at:

More information about the snappy-devel mailing list