joint_limits_interface/manifest.xml causing issues with rosdep

[davetcoleman]

joint_limits_interface/manifest.xml includes a reference to a pre-Hydro package, urdf_interface. This is as intended so that a rosbuild can work pre-Hydro and catkin can work for Groovy, Hydro and forward.

The problem is that when you run:

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

rosdep scans both package.xml and manifest.xml files and throws errors because it can't find the package urdf_interface in Hydro.

I'm not sure what the best course of action would be, perhaps splitting the hydro-devel branch to no longer support rosbuild? This would make syncing updates way more difficult then.

Another option would be to fix rosdep to ignore manifest.xml when in a catkin workspace, or some logic like that. @wjwwood ?

[wjwwood]

@dirk-thomas

[dirk-thomas]

rosdep has no way to figure out if the package is supposed to be wet or dry since it is both. The location in a wet workspace does not allow the conclusion to use only the wet dependencies.

I would highly recommend not to use a single branch for multiple distro especially when when in one of them the package is dry and in another it has been catkinized and is wet.

[wjwwood]

The underlying library here is rospkg, which always prefers manifest.xml. The catkin version of that is catkin_pkg which completely ignores the manifest.xml. This allows the "hybrid" package to build correctly in each case, because rosmake uses rospkg which selects the manifest.xml first, and catkin_make uses catkin_pkg to find packages which ignores the manifest.xml all together.

In the case of rosdep it uses rospkg and will always select the manifest.xml. This is one of the reasons I was against supporting "hybrid" packages. I don't think rosdep has anyway of making the correct decision at this point.

[wjwwood]

You could conceivably add an option to rosdep to make it use catkin_pkg rather than rospkg, but I don't think rosdep could infer the correct thing from the context.

This would likely be an involved change to how rosdep does this...

[davetcoleman]

@adolfo-rt how soon until you guys upgrade to catkin? :)

[adolfo-rt]

The fastest fix would be to change the rosdep dependency from urdf_interface to urdfdom in groovy-devel and hydro-devel. I can then keep a fuerte-backport branch in my fork with all the Fuerte-specifics.

@adolfo-rt how soon until you guys upgrade to catkin? :)

I don't make this call, but I would not expect activity in this front until at least the end of the year.

The upside of having the hybrid wet/dry scripts is that it makes it easier for me to incorporate my work. I understand that this is a self-centered statement, and I don't want to be dragging down the progress of the project; so if the best choice by consensus or policy is to dump official rosbuild support, I'll bite the bullet and accept it.

[davetcoleman]

Adolfo, you seem to be the main developer of ros_control right now so making it easy for your to incorporate your work is a priority. Your commitment to tests and in-line documentation is especially appreciated. For that reason I think we should keep the rosbuild support (but hopefully no longer than the next ROS release).

I think simply removing that one line from the manifest.xml in the Hydro/Groovy branch might be a solution that is easy for you to sync with your fuerte fork. I'm not 100% confident what the best practices are for moving commits between two slightly different branches are, though. I can't think of a perfect solution to this.

[wjwwood]

You can also just remove the manifest.xml before building on Hydro... (rosbuild would not work on hydro).

[davetcoleman]

Yes, currently for the build from source instructions for gazebo_ros_pkgs we are telling users to do rm joint_limits_interface/manifest.xml but I was hoping that was a temporary fix.

[wjwwood]

You can also rename the file in git and have the Fuerte instructions rename the file to manifest.xml, allowing you to drop that step from Hydro instructions.

[davetcoleman]

I like that idea. And we can add it to .gitignore so that the renamed manifext.xml is added back to the repo. @adolfo-rt how does that sound?

[adolfo-rt]

OK to renaming manifest.xml for this package.

[davetcoleman]

PR submitted #108