Revision history [back]

I want to clarify the terms first:

• build dependencies (http://ros.org/reps/rep-0127.html#build-depend-multiple) are things a package needs in order to be build
• run dependencies (http://ros.org/reps/rep-0127.html#run-depend-multiple) are on the one hand things a package needs to be executed and on the other hand for transitive dependencies it provides to other package when they build against this package

Based on that I will first answer your questions 9a and 9b since they will be the foundation for understanding how dependencies of ROS packages map to Debian packages.

Only the run dependencies are used for the dependencies of the Debian packages. Since ros-hydro-urdf does not need ros-hydro-cmake-modules at runtime (but only at build time) it does not declare a run dependency on it. Therefore the Debian package ros-hydro-urdf does not depend on ros-hydro-cmake-modules which result in ros-hydro-cmake-modules not being installed automatically.

Short answers:

9a: Because the urdf package has no run dependency on cmake_modules.

9b: Yes, on the run dependencies are mapped to Debian dependencies.

I want to clarify the terms first:

• build dependencies (http://ros.org/reps/rep-0127.html#build-depend-multiple) are things a package needs in order to be build
• run dependencies (http://ros.org/reps/rep-0127.html#run-depend-multiple) are on the one hand things a package needs to be executed and on the other hand for transitive dependencies it provides to other package when they build against this package

Based on that I will first answer your questions 9a and 9b since they will be the foundation for understanding how dependencies of ROS packages map to Debian packages.

Only the run dependencies are used for the dependencies of the Debian packages. Since ros-hydro-urdf does not need ros-hydro-cmake-modules at runtime (but only at build time) it does not declare a run dependency on it. Therefore the Debian package ros-hydro-urdf does not depend on ros-hydro-cmake-modules which result in ros-hydro-cmake-modules not being installed automatically.

Short answers:

9a: Because the urdf package has no run dependency on cmake_modules.

9b: Yes, on the run dependencies are mapped to Debian dependencies.

I want to clarify the terms first:

• build dependencies (http://ros.org/reps/rep-0127.html#build-depend-multiple) are things a package needs in order to be build
• run dependencies (http://ros.org/reps/rep-0127.html#run-depend-multiple) are on the one hand things a package needs to be executed and on the other hand for transitive dependencies it provides to other package when they build against this package

Based on that I will first answer your questions 9a and 9b since they will be the foundation for understanding how dependencies of ROS packages map to Debian packages.

Only the run dependencies are used for the dependencies of the Debian packages. Since ros-hydro-urdf does not need ros-hydro-cmake-modules at runtime (but only at build time) it does not declare a run dependency on it. Therefore the Debian package ros-hydro-urdf does not depend on ros-hydro-cmake-modules which result in ros-hydro-cmake-modules not being installed automatically.

Short answers:

9a: Because the urdf package has no run dependency on cmake_modules.

9b: Yes, on the run dependencies are mapped to Debian dependencies.

--

The next topic will be rosdep:

Since system dependencies are named very differently on various platforms the rosdep database (stored in these files: https://github.com/ros/rosdistro/tree/master/rosdep) defines a mapping of names (called rosdep keys) to platform specific package names. For dependencies only these rosdep keys are used. In many cases they map 1to1 to Ubuntu packages names.

Besides these system packages there is also a known list of ROS packages. For wet the packages are listed in the rosdistro release file (https://github.com/ros/rosdistro/blob/master/hydro/release.yaml), for dry stacks were the unit of packaging and they are listed in the equivalent legacy release file (https://code.google.com/p/ros-dry-releases/source/browse/trunk/distros/groovy.rosdistro#210). [Hydro does not have any released dry packages anymore.]

Now to the answer of question 9c: for

For wet packages dependencies on system packages and ROS packages are not specified differently. The tools will automatically figure out of the name is a ROS package or a rosdep key. For dry packages system dependencies are specified using the rosdep tag and dependencies on other ROS packages with the depend tag. For dry packages both type of dependencies - rosdep as well as depend - are used for the Debian packages - they do not differentiate between build and run dependencies. [E.g. for ROS packages the Debian package name starts with ros-DISTRO- which will automatically be added during the release process.]

I want to clarify the terms first:

• build dependencies (http://ros.org/reps/rep-0127.html#build-depend-multiple) are things a package needs in order to be build
• run dependencies (http://ros.org/reps/rep-0127.html#run-depend-multiple) are on the one hand things a package needs to be executed and on the other hand for transitive dependencies it provides to other package when they build against this package

Based on that I will first answer your questions 9a and 9b since they will be the foundation for understanding how dependencies of ROS packages map to Debian packages.

Only the run dependencies are used for the dependencies of the Debian packages. Since ros-hydro-urdf does not need ros-hydro-cmake-modules at runtime (but only at build time) it does not declare a run dependency on it. Therefore the Debian package ros-hydro-urdf does not depend on ros-hydro-cmake-modules which result in ros-hydro-cmake-modules not being installed automatically.

Short answers:

9a: Because the urdf package has no run dependency on cmake_modules.

9b: Yes, on the run dependencies are mapped to Debian dependencies.

--

The next topic will be rosdep:

Since system dependencies are named very differently on various platforms the rosdep database (stored in these files: https://github.com/ros/rosdistro/tree/master/rosdep) defines a mapping of names (called rosdep keys) to platform specific package names. For dependencies only these rosdep keys are used. In many cases they map 1to1 to Ubuntu packages names.

Besides these system packages there is also a known list of ROS packages. For wet the packages are listed in the rosdistro release file (https://github.com/ros/rosdistro/blob/master/hydro/release.yaml), for dry stacks were the unit of packaging and they are listed in the equivalent legacy release file (https://code.google.com/p/ros-dry-releases/source/browse/trunk/distros/groovy.rosdistro#210). [Hydro does not have any released dry packages anymore.]

Now to the answer of question 9c:

For wet packages dependencies on system packages and ROS packages are not specified differently. The tools will automatically figure out of the name is a ROS package or a rosdep key. For dry packages system dependencies are specified using the rosdep tag and dependencies on other ROS packages with the depend tag. For dry packages both type of dependencies - rosdep as well as depend - are used for the Debian packages - they do not differentiate between build and run dependencies. [E.g. for ROS packages the Debian package name starts with ros-DISTRO- which will automatically be added during the release process.]

I want to clarify the terms first:

• build dependencies (http://ros.org/reps/rep-0127.html#build-depend-multiple) are things a package needs in order to be build
• run dependencies (http://ros.org/reps/rep-0127.html#run-depend-multiple) are on the one hand things a package needs to be executed and on the other hand for transitive dependencies it provides to other package when they build against this package

Based on that I will first answer your questions 9a and 9b since they will be the foundation for understanding how dependencies of ROS packages map to Debian packages.

Only the run dependencies are used for the dependencies of the Debian packages. Since ros-hydro-urdf does not need ros-hydro-cmake-modules at runtime (but only at build time) it does not declare a run dependency on it. Therefore the Debian package ros-hydro-urdf does not depend on ros-hydro-cmake-modules which result in ros-hydro-cmake-modules not being installed automatically.

Short answers:

9a: Because the urdf package has no run dependency on cmake_modules.

9b: Yes, on the run dependencies are mapped to Debian dependencies.

--

The next topic will be rosdep:

Since system dependencies are named very differently on various platforms the rosdep database (stored in these files: https://github.com/ros/rosdistro/tree/master/rosdep) defines a mapping of names (called rosdep keys) to platform specific package names. For dependencies only these rosdep keys are used. In many cases they map 1to1 to Ubuntu packages names.

Besides these system packages there is also a known list of ROS packages. For wet the packages are listed in the rosdistro release file (https://github.com/ros/rosdistro/blob/master/hydro/release.yaml), for dry stacks were the unit of packaging and they are listed in the equivalent legacy release file (https://code.google.com/p/ros-dry-releases/source/browse/trunk/distros/groovy.rosdistro#210). [Hydro does not have any released dry packages anymore.]

Now to the answer of question 9c:

For wet packages dependencies on system packages and ROS packages are not specified differently. The tools will automatically figure out of the name is a ROS package or a rosdep key. For dry packages system dependencies are specified using the rosdep tag and dependencies on other ROS packages with the depend tag. For dry packages both type of dependencies - rosdep as well as depend - are used for the Debian packages - they do not differentiate between build and run dependencies. [E.g. for ROS packages the Debian package name starts with ros-DISTRO- which will automatically be added during the release process.]

--

Test 1

rospack needs to provide the necessary information to enable building dry packages on top of wet packages. Since the dry and wet world have very different concepts rospack does not look very consistent in its behavior. But most of it is necessary to provide support for building dry packages.

1b: Yes, rospack does only traverse the run dependencies.

Why is that the case. E.g. a dry package D depends on a wet package W. W itself build depends on Wb and run depends on Wr. Everything D cares about is that it needs W and Wr to build and run itself.

1a: Since cmake_modules is not a run dependency of example_package it is therefore not detected by rospack.

1c: Yes and no. I would say rospack fully supports the use cases of building dry on top of wet. But due to the complexity of that backward compatibility between both build systems the result does sometime look different from what the user would expect.

--

Test 2

First, your statement that "cmake_modules is included in the rosdep definitions" is not true. It is not listed in any of the rosdep files (https://github.com/ros/rosdistro/tree/master/rosdep) but only as a ROS package in the rosdistro release file (https://github.com/ros/rosdistro/blob/master/hydro/release.yaml).

2a: rospack looks for a ROS package cmake_modules on your system (anywhere in the ROS_PACKAGE_PATH). Since it does not find the ROS package anywhere it complains that it is missing.

2b: After not finding a ROS package with that name rospack will query rosdep for a rosdep key cmake_modules. But since rosdep does not know that key either it generates an error message.

2c: The error message states "package/stack 'example_package' depends on non-existent package 'cmake_modules'" (because no ROS package with that name was found on your system) and "rosdep claims that it is not a system dependency" (since rosdep does not have a rosdep key with that name).

Then it suggests the following two potential fixes to the user:

• "Check the ROS_PACKAGE_PATH" in order to add a path where the ROS package can be found
• "try calling 'rosdep update'" in order to fetch a newer rosdep database in the case that cmake_modules has recently been added there as a system dependency