Collecting some discussion input here about use cases:
- Typically this is interesting for slots provided by the gadget itself, if one goes looking for interfaces that can have slots provided by a gadget we encounters things like serial-port etc., where auto-connection alone is not enough because there might be usually many candidates plugs and slots.
- The application requiring those slots might come with the device originally or not (it might enable some important functionality but might not have been available when the device first shipped, it might be an add-on).
- For an interface like camera provided by core and where auto-connection is not allowed by default, auto-connecting via the a declaration is a viable path as long as the application comes from a store controlled by the gadget/device publisher. it is not a viable path if the application is more generic and comes from a store to which they have access but don’t control (like the global store).
It’s important to note that for an appliance kind of device (no user usually present to trigger snapd actions):
snaps either come via seeding, or there is a snap with snapd-control that can install further snaps and so in in principle could do connections too.
With these considerations it seems there are two related areas to address:
- the gadget should be able to define connections between snaps that comes with the model (naively this means at seeding but see 2nd point)
- we need to explore ways to update the model assertion of a gadget to a new revision, and carry out any reasonable effect of that, like installing further required snaps (what about removing?)
- unless we specify the connections in the model assertions, not the gadget (that doesn’t seem appropriate though), such model revision update would need to be potentially in sync with a gadget update; one approach would be to have a trigger for the model revision update from the gadgets