rosdep does not enforce version_gte tag

[awesomebytes]

Following this documentation:
http://www.ros.org/reps/rep-0127.html#build-depend-multiple

I added to my package.xml the line:

  <build_depend version_gte="1.10.6">sensor_msgs</build_depend>

And I executed (at my workspace, just over src folder):

rosdep install --from-paths src --ignore-src --rosdistro hydro

And I got:

#All required rosdeps installed succesfully

But my system ros-hydro-sensor-msgs is:

$ dpkg -l | grep sensor-msgs
ii  ros-hydro-sensor-msgs                        1.10.2-0precise-20131010-0201-+0000

The package itself is: https://github.com/pal-robotics/object_recognition_clusters just in case.

[wjwwood]

rosdep was designed before versions of dependencies were captured in manifest files, i.e. rosbuild and manifest.xml. It was also designed to resolve system dependencies and not just ROS packages which are released. Because of this rosdep makes the assumption that the version of installed packages are correct. For instance, if you have the rosdep key boost, it should resolve to either a generic OS package manager specific key like libboost-all-dev if the version is not important, or something like libboost-all-1.48-dev if it is. For ROS packages like sensor_msgs, the version is always taken as the the latest available.

Therefore entries like version_gte in a package.xml are not used by rosdep and are instead only used for packaging into systems like Debian where the versioned dependencies can be captured outside of rosdep.

I agree that ideally this should be something that rosdep handles better or even checks for at all, but the effort to refactor out these assumptions in rosdep will be very high. Because of this I would mark this as won't fix for now.

However, @NikolausDemmel is just now starting a GSoC to work on a improved version of rosdep and he should consider this issue in the design of the new tool.

[wjwwood]

@awesomebytes I'm sorry if this is an inconvenient answer for now, but if this does address your question can you please close this issue? Otherwise, feel free to continue the discussion.

[awesomebytes]

Thank you for your fast response @wjwwood, I'm not so happy with the answer as I thought it would be a mere bug or that I just forgot to do something.
Having had problems in the past with different versions of ROS packages (MoveIt! and Gazebo for example) that crashed on runtime (linking to different versions of libs, executing deprecated python code, behaviour changed in an update...) I can see this happening in the future.
If there is nothing to do (as I don't know the details of rosdep implementation) I'll close the issue but I would prefer to keep it alive, maybe as an improvement?

[wjwwood]

You can feel free to keep it open, but I won't be spending anytime on it for now since we have plans to address this in the new tool.

[NikolausDemmel]

@awesomebytes: What would you expect rosdep to do in this situation? For apt, the only action I can imagine right now for an already installed (ros-) package is upgrading to the latest version and erroring/warning if the versioned dependency is not satisfied by that. (It could potentially also try to update the apt cache if it is outdated).

[awesomebytes]

@NikolausDemmel that's exactly what I was expecting rosdep to do! Or at least give me a warning stating that the dependency is installed but in a lower version and that might cause trouble.

[NikolausDemmel]

@awesomebytes: Ok, I'll keep it in mind for the new tool. Not sure if we will be able to include it in the current version.

[awesomebytes]

@NikolausDemmel Ok, thank you for your interest :) and also congratulations on your GSoC!

[NikolausDemmel]

Thanks ;-). We're just really starting now and one of the first things involves collecting current shortcomings of rosdep we would like to alleviate in the new tool, so these kinds of requests with concrete/relevant use case are very valuable.

[mdhorn]

+1
I just ran into the same "problem". I was using the newer, format 2 of package.xml, but I had the same expectation of rosdep.
I was surprised when I set version_gte in the package.xml and rosdep installed a lower version.

[peci1]

I agree that with Debian packages, there are just two options - update to latest, or fail (or ignore the version). But with pip, things get more interesting, because you can easily force version number.

I know that REP-140 has been there for a long time, but wouldn't it deserve a mention about rosdep not supporting these tags at all? Or at least a link to this issue? I know that other tools than rosdep may process the package manifest, but rosdep is the first I think about when I see a package manifest.

[realtime-neil]

What's the status of this issue? I wound up here after my (failed) attempts to get rosdep to pass version information to apt.

[ghost]

I would also like to know the status of this issue?
Also; what is this "new tool" that is being refferenced? is it for ROS2 or is it something that will resolve this issue for ROS users as well?

[NikolausDemmel]

The status is that noone is working on this. Also for ROS2, there is currently no work towards replacing rosdep AFAIK.

A while ago there was work on a "new tool", xylem, which was intended as a replacement for rosdep with a ROS-independent core. I belive @wjwwood started it, then I worked on this for a while and together with @wjwwood and @tfoote we had some discussion on how this issue should be addressed in xylem (see https://xylem.readthedocs.io/en/latest/design.html#versions-in-rules-files). However, due to bandwidth limitations (I started a new job), this never reached beyond prototype stage and its not ready to replace rosdep. In particular version checking wasn't even implemented in the prototype, IIRC. From OSRF side, I guess rosdep has been working well enough, so other projects were more pressing.

[wjwwood]

That's an accurate summary.

[ghost]

Thanks for the accurate and quick reply. We'll go back to using our own setup script then.