rosdep returns "no definition" for all packages in SpaceROS Docker image

[Bckempa]

Undesired Behavior

Attempting to run rosdep in a SpaceROS container results in every key returning the error:
No definition of [<PACKAGE_NAME>] for OS version [focal]

Cause

The SpaceROS Docker image is based on an Ubuntu 20.04 Focal Fossa image, but SpaceROS tracks the ROS2 Rolling Ridley distribution which removes support for 20.04 focal in favor of Ubuntu 22.04 Jammy Jellyfish.
See discussion on relevant ROS issue and the commit that removed focal.

Solutions

1. Update base image
   Nvidia has not published an Ubuntu 22.04 cudagl docker image yet, but might do so after the official Ubuntu release on April 21st.
2. Declare rosdep unsupported in SpaceROS image
3. Document overrides
   The rosdep commands can run by overriding either the rosdistro or os keys:
   rosdep install --rosdistro=foxy --from-paths src/ --ignore-src
rosdep install --os=ubuntu:jammy --from-paths src/ --ignore-src
   There are some potential issues with this but it's "good enough™️" to get most packages running in my testing.
4. Switch base image
   This would involve either creating a custom Ubuntu 22.04 cudagl image or finding a new base entirely.

Action

Either keep an issue open to update the base image when Nvidia releases cudagl on Ubuntu 22.04, and/or add a section on rosdep to the README.md based on the selected solution

[nuclearsandwich]

There are a couple of different issues wrapped up in this particular problem report

The rosdep installation using Rolling on Focal should work without overriding the rosdistro or os. If it fails that means it is exposing other dependency problems which are worth reporting directly.

Ubuntu Focal is no longer supported as a tier 1 binary installation platform for ROS 2 Rolling but it is a tier 3 "community supported" distribution and so far at least, rosdep is expected to work and satisfy system dependencies as long as you're building all of ROS 2 from source.

Failures for the rosdep install step of the embedded docker builds will most often indicate that we've "missed" a ROS package that we depend on which needs to be built from source.
Most recently, changes to the organization of the orocos_kdl dependency for ROS 2 and the switch in Rolling to Fast-DDS as the default rmw (and some dependency juggling side effects from it) have changed the set of packages that we want to ignore rosdep dependency resolution for.
#4 updates the rosdep command to skip additional packages and #9 will make sure that changes to the repos file for Space ROS are picked up by subsequent docker builds, however we will still need to periodically check that the repos file is up-to-date by regenerating it using rosinstall_generator (ticketed as space-ros/space-ros#34).

When building additional ROS 2 software using these docker images as a base, users will need to use the same list of skipped dependencies (as well as any additional skips specific to their packages) and will need to build any ROS packages they depend on from source if they aren't already present in the underlay.

---

Updating the base image is not required nor is it a correct solution to rosdep installation errors in most cases. However we would like to update Space ROS's base OS to Ubuntu Jammy. It should already build on Jammy today although as you've found our current higher level base images would need to change unless a Jammy-based image becomes available.

I do expect that we'll move to Ubuntu Jammy in the next couple of months, if not weeks.

[Bckempa]

Thanks for the detailed write-up. I'm not clear on exactly what changed but my image builds no longer encounter this issue without any modification to the rosdep command so I'll close as resolved.