Content interface supports multiple sources, but only one destination

[Kyle Fazzari]

Take the following slot definition:

    slots:
      shared:
        content: shared
        interface: content
        read:
          - /dir1
          - /dir2

Pair it with the following corresponding plug definition:

    plugs:
      shared:
        content: shared
        interface: content
        target: my-target

Note that the slot supports multiple sources, and the plug supports only a single target. The result isn't particularly useful: first, <slot snap>/dir1 is bind-mounted to <plug snap>/my-target, then <slot snap>/dir2 is bind-mounted again to <plug snap>/my-target. So <plug snap>/my-target is always <slot snap>/dir2.

I look at this interface and can't come up with a rational user expectation for what _should_ happen in this case. Is what's currently happening expected? How do we expect multiple sources to be useful?

[Zygmunt Krynicki (zyga)]

I think this was a bug in the original design. Ideally we would allow some semantics (e.g. unification) or require matching number of targets. Before we decide what that should do I think we should disallow any content slots that have more than one entry in either read or write.

[Zygmunt Krynicki (zyga)]

This is addressed by the improved design [1] and there's a PR [2] pending that will enable it. That PR, among other things, will allow connecting multiple things into one
place with sensible semantics.

[1] https://forum.snapcraft.io/t/improvements-in-the-content-interface/2387
[2] https://github.com/snapcore/snapd/pull/4068

[Zygmunt Krynicki (zyga)]

This has been merged and will be available in 2.31. One support PR for being able to use it in read-only $SNAP is still pending but it already works for $SNAP_DATA and $SNAP_COMMON based content sharing.

[Zygmunt Krynicki (zyga)]

This has been released and with several other fixes is available in 2.32.x