Policy on run_depends for external optional binary packages

edit

As you've pointed out, we don't have recommended or optional dependencies in the package.xml format. This was intentional for simplicity because modeling things like optional and recommended in the tools would be complicated. Plus not all package managers support this concept so we'd have to do something about that too.

I would recommend having all "optional" dependencies listed as run_depend dependencies. If you would like to change that to recommended in your generated Debian package, then you can patch the debian/control file in your package's release repository. The patch will carry over, release to release, automatically (as long as it applies cleanly). This is an example of which file and branch you would need to edit and commit to in order to affect this change:

https://github.com/ros-gbp/rviz-relea...

You could just add a line for the recommended dependencies there. And you could modify the template line which places the Depends and add an exclusion for your optional dependency. That way it doesn't get listed in Depends but it is in your custom Recommends line.

If you want to do it the "catkin" way, I would recommend using another package to model the optional dependency. Let's assume your package is called foo, then I would make a foo_with_Y package which has a hard dependency on both foo and Y. Then users could install foo_with_Y if they wanted the additional functionality of Y. This scales better when Y provides not just a command line tool, but a library or interface code. This would allow you to split the Y specific part of your package into foo_with_Y, preventing foo from needing Y at build time. This is generally accomplished with conditional imports in Python or plugins in either C++ or Python.

If you really wanted to, then you could still modify the debian/control file for foo to Recommends ros-<version>-foo-with-Y afterwards as well.