We became aware of an issue where recent snapd doesn’t function very well if used in the old-named ubuntu-core snap instead of the new-named core snap. We need to address this before the release of 2.25 and 2.26.
This seems to be caused by hard-coding core as the name of the snap we look at looking for snap-confine and other execute-from-core assets.
There are a few obvious places where this is a factor (re-exec checks, usage of snap-confine, detection of the apparmor profile) but there may be others. We should spend the better part of tomorrow focusing on this issue.
The issue is simple, we started hard-coding the-name-of-the-snap-shipping-snapd as core. In the past we preferred core but also had a fallback to ubuntu-core. We no longer have that. The when it broke part is less clear but I plan to find out (tomorrow)
The problem is that ubuntu-core is very much a second class citizen by now.
We only need a somewhat recent version so that we have a snapd in ubuntu-core that will auto-transition the existing ubuntu-core to the proper core snap. However to do this we don’t actually need to release ubuntu-core regularly (and keep all the compatibility baggage in snapd). The population of ubuntu-core users is very small and you only get it by default if you start with ubuntu 16.04.1 (snapd 2.0.10) which is obsolete by now and probably has more problems).
Therefore I would suggest we do the following:
freeze the ubuntu-core snap in all channels
stop auto-building the ubuntu-core snap
disallow installing ubuntu-core from snapd (i.e. snap install ubuntu-core should fail)
add a spread-cron (or similar) test that ensures that when we have the latest ubuntu-core it will correctly transition to the latest snapd
