Resolve "Duplicated keys in rosdep database"
Closes #10 (closed)
Merge request reports
Activity
assigned to @miguel.prada
mentioned in issue #10 (closed)
Have you been able to test this? I'm guessing not, since it's a bit convoluted.
I'm confused by the naming of the RoboCeption related packages. Why do some of them have the
ros-kinetic-prefix and some don't (and in some cases we have both versions)? Are they library packages and ROS wrapper packages on top or are they just not consistent in their naming? If it's the former, shouldn't we define rosdep keys for both (the lib and the ROS package)?A closer look at the packages declared in our
rosdepdatabase suggest the following convention is used:- rosdep keys
rcXXXXmap to nonros-kinetic-prefixed packages, which I guess are not ROS packages - rosdep keys
rc_XXXXmap toros-kinetic-prefixed packages, which I guess are ROS wrappers on top of thercXXXXones
If that's correct, then shouldn't we make
rc_dynamics_apipoint toros-kinetic-rc-dynamics-apiand add a newrcdynamics_apipointing torc-dynamics-api?- rosdep keys
If that's correct, then shouldn't we make
rc_dynamics_apipoint toros-kinetic-rc-dynamics-apiand add a newrcdynamics_apipointing torc-dynamics-api?No.
For some of the packages, they started using the
rc-prefix and then switched toros-kinetic-rc.The package you refer to is an example:
rc-dynamics-apipoint to version 0.7.0 of the package, whileros-kinetic-rc-dynamics-apipoints to the upgrade version 0.7.1 of the same package. So that is why in this MR I only keep the latest version (the older one is deprecated).-
I suggest we merge this MR which is also blocking !25 (merged) , and later on decide if we want to rename the rosdep mappings.
mentioned in commit 053d5530
