Request for global autoconnect of ROS foundation snaps


I’d like to request for the autoconnection of the content interface (slots) provided by the snaps listed below. Those snaps all contains a set (small to large) of the ROS framework and that for different versions of said framework. They overall contain executables and libraries used at runtime by other snaps plugging to them. They are part of a larger body of work that natively enables this feature (ROS content sharing) in snapcraft (see #4221) and were developed following the model established by the KDE Framework snaps. An example of a snap using this feature can be found here.

Not sure whether I provide all the necessary info, so of course feel free to ping me.



  • ros-foxy-desktop
  • ros-foxy-ros-base
  • ros-foxy-ros-core

  • ros-humble-desktop
  • ros-humble-ros-base
  • ros-humble-ros-core

  • ros-noetic-desktop
  • ros-noetic-robot
  • ros-noetic-ros-base
  • ros-noetic-ros-core

Hello @review-team :wave:,
is there any further info I can provide to help here?

Hi @artivis

Unless other reviewer corrects me, I don’t see a reason why we should not grant global auto-connect to these content snaps. Thus, +1 from me.

+1 from me as well for global auto-connect of the named content snaps. Thanks.

Hello :wave: ,

Is there anything else required to get the auto-connect?


Hey @artivis ,

Before proceeding, can you please rename the content attribute value of each of the snaps so then it is clear for plugging snaps what they are connecting to? e.g. I see you have the same:

    interface: content
    content: ros-foxy
    - /

for the 3 ros-foxy-desktop, ros-foxy-ros-base and ros-foxy-ros-core. Same thing for the other set of snaps.

This discussion should help if this is still not clear.

After discussing with @emitorino, I’ll bring some more details to this thread.

Those snap contains sets of the ROS framework. foxy/humble/noetic are versions, quite analogous to 18/20/22. The suffixes core/base/desktop are super-sets of the framework, desktop contains base (and some) which in turn contains core (and some). All those terms are well established in the ROS project.

For a given version (say foxy), snaps are partially compatible in the sense that a ros-foxy plug expecting the core subset can connect to a ros-foxy slot on either of core/base or desktop and expect to find the bits it requires.
The inverse is not true. A ros-foxy plug expecting the desktop set will not work if connected to the ros-foxy plug on core nor on base.

This partial compatibility, and thus the naming, is meant as a feature not a bug. E.g., given several consumer snaps with different foxy plugs (core/base/desktop), rather than installing all three provider snaps, one could deploy only the greater super-set required (desktop) and connect all consumers to it.

I need to mull this over a bit to see what’s best. I’ll comeback to this thread asap :+1: .


After internal discussion we came up with the following mitigation.

Each snap would declare their specific slot, that is e.g. the ros-noetic-ros-core snap would declare a ros-noetic-ros-core slot; the ros-foxy-desktop snap would declare a ros-foxy-desktop slot.

In addition, super-set snaps would declare additional slots for the lower sets they encompass since the content of those lower sets is also present. These additional slots would also be auto-connectable. E.g. the ros-foxy-desktop snap would also declare the ros-foxy-ros-base & ros-foxy-ros-core slots.

A full example for the foxy version is,

  • the snap ros-foxy-ros-core has the slot:
    • ros-foxy-ros-core
  • the snap ros-foxy-ros-base has the slots:
    • ros-foxy-ros-core
    • ros-foxy-ros-base
  • the snap ros-foxy-desktop has the slot:
    • ros-foxy-ros-core
    • ros-foxy-ros-base
    • ros-foxy-desktop

And equivalently for humble & noetic variants.

Reciprocally, plugs would also have to adopt this more exhaustive naming schema of course.

This more meaningful naming addresses the concern of a (current) ros-foxy plug expecting the ‘desktop’ set to wrongly auto-connecting to a (current) ros-foxy slot only providing the ‘core’ set for instance.

@emitorino Any thoughts? Would that address the concern you raised?

1 Like

@artivis thanks for the analysis. The proposal looks good for me, and if they work for the ros ecosystem, I think we can proceed with the declaration grant. Can other @reviewers please check this?