This yaml is using an invalid name for 'default-provider', is specifying a non-existent 'content' value and does not ship /run/consumer/current/shared1 or shared2. See https://github.com/snapcore/snapd/wiki/Interfaces#content for how these interface attributes are to be used.
Since the ubuntu-app-platform has this in its yaml:
your snapcraft.yaml should be something like for the ubuntu-app-platform snap:
plugs:
uap1:
content: ubuntu-app-platform1
default-provider: ubuntu-app-platform
target: shared1
where 'content' is the same as the 'content' value in the providing snap (ie, ubuntu-app-platform1), 'default-provider' is the name of the providing snap (ie, ubuntu-app-platform) and 'target' is the name of a directory in $SNAP for you snap (this directory *must* exist because it cannot be created for you).
2. 'sudo snap install ./consumer*snap --dangerous' results in autoconnecting ubuntu-app-platfrom despite all of the above issues with your snap.yaml. This is because of a too-lenient snap declaration.
3. Because of the too lenient snap declaration for ubuntu-app-platform, if you have a snap that plugs both ubuntu-app-platform and mir-libs, since mir-libs does not currently have a snap declaration, both plugs would be auto-connected to ubuntu-app-platform and mir-libs skipped.
Note that local unasserted snap installs of content snaps don't have a signed snap declaration on the system, so only the base declaration can be consulted. This accounts for differences in behavior with snaps installed with and without --dangerous.
I have adjusted the snap declaration for ubuntu-app-platform to have:
This means that the auto-connection can only happen with the plugging snap that uses "content: ubuntu-app-platform1", which is precisely how it is supposed to work.
To fix your snap for ubuntu-app-platform and mir-libs, use this yaml:
then create the shared1 and shared2 directories beside your snapcraft.yaml file, then snapcraft will generate a snap that will work for you. Specifically, if you install ubuntu-app-platform first, upon install of your snap ubuntu-app-platform will be mounted on $SNAP/shared1 and nothing will be mounted on $SNAP/shared2 (since mir-libs doesn't yet have a snap declaration for auto-connection). When you 'sudo snap connect consumer:ml0 mir-libs:mir-libs', then mir-libs will be mounted on $SNAP/shared2 (after you first 'sudo /usr/lib/snapd/snap-discard-ns consumer').
In summary, there is no bug in snapd, but there are bugs in your snapcraft.yaml and there was a bug in the ubuntu-app-platform's snap declaration. Since the snap declaration is now fixed, marking Fixed Released.
There are several things going on:
1. your snap is using this for plugging the ubuntu-app-platform content interface:
plugs: provider: provider1:shared1 provider: provider2:shared2
shared1:
content: shared1
interface: content
target: shared1
default-
shared2:
content: shared2
interface: content
target: shared2
default-
This yaml is using an invalid name for 'default-provider', is specifying a non-existent 'content' value and does not ship /run/consumer/ current/ shared1 or shared2. See https:/ /github. com/snapcore/ snapd/wiki/ Interfaces# content for how these interface attributes are to be used.
Since the ubuntu-app-platform has this in its yaml:
slots: app-platform1
platform:
content: ubuntu-
interface: content
read:
- .
your snapcraft.yaml should be something like for the ubuntu-app-platform snap: app-platform1 provider: ubuntu-app-platform
plugs:
uap1:
content: ubuntu-
default-
target: shared1
where 'content' is the same as the 'content' value in the providing snap (ie, ubuntu- app-platform1) , 'default-provider' is the name of the providing snap (ie, ubuntu- app-platform) and 'target' is the name of a directory in $SNAP for you snap (this directory *must* exist because it cannot be created for you).
2. 'sudo snap install ./consumer*snap --dangerous' results in autoconnecting ubuntu-app-platfrom despite all of the above issues with your snap.yaml. This is because of a too-lenient snap declaration.
3. Because of the too lenient snap declaration for ubuntu- app-platform, if you have a snap that plugs both ubuntu-app-platform and mir-libs, since mir-libs does not currently have a snap declaration, both plugs would be auto-connected to ubuntu-app-platform and mir-libs skipped.
Note that local unasserted snap installs of content snaps don't have a signed snap declaration on the system, so only the base declaration can be consulted. This accounts for differences in behavior with snaps installed with and without --dangerous.
I have adjusted the snap declaration for ubuntu-app-platform to have:
slots: auto-connection :
plug-attribute s:
slot-attribute s: app-platform1
content:
allow-
-
content: $SLOT(content)
content: ubuntu-
This means that the auto-connection can only happen with the plugging snap that uses "content: ubuntu- app-platform1" , which is precisely how it is supposed to work.
To fix your snap for ubuntu-app-platform and mir-libs, use this yaml:
plugs: app-platform1 provider: ubuntu-app-platform provider: mir-libs
uap1:
interface: content
content: ubuntu-
target: shared1
default-
ml0:
interface: content
content: mir0
target: shared2
default-
then create the shared1 and shared2 directories beside your snapcraft.yaml file, then snapcraft will generate a snap that will work for you. Specifically, if you install ubuntu-app-platform first, upon install of your snap ubuntu-app-platform will be mounted on $SNAP/shared1 and nothing will be mounted on $SNAP/shared2 (since mir-libs doesn't yet have a snap declaration for auto-connection). When you 'sudo snap connect consumer:ml0 mir-libs:mir-libs', then mir-libs will be mounted on $SNAP/shared2 (after you first 'sudo /usr/lib/ snapd/snap- discard- ns consumer').
In summary, there is no bug in snapd, but there are bugs in your snapcraft.yaml and there was a bug in the ubuntu- app-platform' s snap declaration. Since the snap declaration is now fixed, marking Fixed Released.