Ask Your Question
0

Policy on run_depends for external optional binary packages

asked 2015-02-02 11:06:32 -0500

dornhege gravatar image
  1. I have a catkin package that calls (via system) an additional program in a standard ubuntu package. Let's call that X. Although X is not needed to build or start my package's binary, there is no real use without this. So, I believe X should definitely be a run_depend.

  2. However, via a command line switch, one can optionally use another system package Y for additional functionality. Should this also be a run_depend? In principle it isn't needed for functionality, but if someone wants to use the extras without Y it will fail. If all possible functionality is required, Y would need to be a run_depend also.

X could also be an actual dependency in the debian package and Y maybe appear under "recommended packages" in apt-get, although I don't think we have an option to declare that. I'm mainly concerned about the released deb package here and how that shows up in apt-get.

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
1

answered 2015-02-02 12:50:44 -0500

William gravatar image

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.

edit flag offensive delete link more

Comments

I have decided to actually change the debian/control file as it is easier than I thought. At the program side I could automatically fall back to without_Y functionality.

dornhege gravatar imagedornhege ( 2015-02-05 03:56:31 -0500 )edit
2

answered 2015-02-02 12:10:34 -0500

ahendrix gravatar image

deb packages have a "recommends" field which does what you suggest; it marks packages as recommended, but not required. In practice, users who install your package manually will get the recommended packages, and users who install is as a dependency of something else will not get the recommended packages.

The ROS package.xml format has no notion of "recommended" or "optional" dependencies.

When adding dependencies, keep in mind that a large portion of the ROS community does not use Ubuntu, and because of this, I recommend that you list all of your dependencies in your package.xml.

If you really, really want to add a recommended dependency to your package, you can modify the debian packaging files that are generated by bloom when releasing your package.

edit flag offensive delete link more

Comments

I think I'll leave the packaging files alone. My package works fine as long as no one requests Y. Should I make this a run_depend then, although it is not required for basic functionality?

dornhege gravatar imagedornhege ( 2015-02-02 12:36:33 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2015-02-02 11:06:32 -0500

Seen: 189 times

Last updated: Feb 02 '15