fix rosdep keys

[christian-rauch]

Description of the changes:

This fixes the rosdep keys so that rosdep install --from-paths src --ignore-src -y can be used to resolve dependencies. I am also converting some messages to STATUS messages so that colcon/catkin do not print on stderr if everything goes well.

Required before submitting a Pull Request:

• [x] I reviewed CONTRIBUTING.md
• [x] I built my changes locally
• [ ] I tested my changes with a device
• [ ] I changed both the ROS1 and ROS2 branches

I tested changes on:

• [ ] Windows
• [x] Linux
• [x] ROS1
• [ ] ROS2

[progtologist]

Instead of removing the K4A key, wouldn't it be a better solution to add a rosdep entry so that K4A points to [k4a-tools, libk4a1.4, libk4a1.4-dev]?

[christian-rauch]

Instead of removing the K4A key, wouldn't it be a better solution to add a rosdep entry so that K4A points to [k4a-tools, libk4a1.4, libk4a1.4-dev]?

That would require adding the packages to the ROS repo. Currently, those packages are hosted in a Microsoft repo. Not sure how this would work, but you either have to copy those Debian packages from the Microsoft to the ROS repo, or "bloom" Azure-Kinect-Sensor-SDK including its binary dependencies.

Alternatively, a package.xml should be added to the Azure-Kinect-Sensor-SDK repo in order to build at least the open source parts of it.

[progtologist]

Thx Christian for the response, I tried to just get the keys into rosdep (mentioned PR) but they are not accepted if the SDK is not into canonical's APT servers. I think we should still maybe leave the K4A entries for custom rosdep definitions, as discussed in the PR.

[christian-rauch]

I tried to just get the keys into rosdep (mentioned PR) but they are not accepted if the SDK is not into canonical's APT servers.

Yes, rosdep keys have to reference official first-party packages, either in the Ubuntu or the ROS repo. They cannot depend on a third-party repo.

I think we should still maybe leave the K4A entries for custom rosdep definitions, as discussed in the PR.

The K4A key cannot be solved via rosdep at the moment. Are you maintaining custom rosdep definitions? Even if it works for you, the key will break rosdep for all others. This is the reason I want to remove it now.

I originally added that key myself in order to build the library from source in a workspace as a dependency for the ROS node. After I realised that it depends on a binary proprietary module, I switched to installing the Debian package manually. Hence, when following the official documentation on installing the library / SDK via the Microsoft repo, you do not need the rosdep key.

[progtologist]

Makes sense, not everyone will want to or even understand that they need to have custom rosdep definitions to make this work. Feel free to remove it!