-
-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Version of ROS package dependencies #440
Comments
I am not 100% sure about this, but if I recall correctly given the frequent ABI breakage inside ROS packages, the idea was to rely on mutex packages rather then |
Update: I have uploaded my custom packages to a public channel. If interested, replicate the issue with this env file name: conda_test_env
channels:
- conda-forge
- robostack-staging
- iit_hhcm
dependencies:
- ros-noetic-desktop-full
- cartesian-interface
- xbot2
- modelinterfacerbdl
- xbot2-gui
- iit-centauro-ros-pkg |
Update: this environment can be solved and works fine (so far) name: conda_test_env
channels:
- conda-forge
- robostack-staging
- iit_hhcm
dependencies:
- ros-noetic-desktop-full
- ros-noetic-rosmon
- cartesian-interface
- xbot2
- modelinterfacerbdl
- xbot2-gui
- iit-centauro-ros-pkg
- ros-noetic-geometric-shapes==0.7.3 # because the only available moveit build links against 0.7.3
- ros-noetic-gazebo-ros==2.9.2=py39h67aadc1_15 # workaround for [issue](https://github.com/RoboStack/ros-noetic/issues/415) |
This is not true. Please note that we introduced SONAMES in Moveit and related packages (later including geometric_shapes) in 2016. The MoveIt stack is one of few in ROS that use SONAMES, we use it very drastically (by binding the SONAME to the release version) and I explained why in my talk at ROSCon back then. |
Hi @alaurenzi - many thanks for reporting this! This is indeed a problem that we should tackle. I think we should add |
Solution to issue cannot be found in the documentation.
Issue
Dear maintainers,
ROS packages typically link against their dependencies using a soname that includes the whole version number down to the patch version.
Example (truncated):
Notice here, for instance, the requirement for
libgeometric_shapes.so.0.7.3
.However, when listing the dependencies of
ros-noetic-moveit-core
(which provides the above library), I see no version requirements at all in any of the ros package dependencies.Indeed, it has happened to me that the mamba solver would generate an environment with a
ros-noetic-moveit-core
requiringros-noetic-geometric-shapes==0.7.3
, but havingros-noetic-geometric-shapes==0.7.5
installed. This of course leads to runtime link errors.Now it is unfortunately not immediately possible for me to provide an MRE as it involves custom packages that I'm building and hosting on a local channel. This is more to understand what is the mechanism that should enforce correct versions. There could be a problem in my recipes that causes this behavior.
Thanks for your insight. I'll work towards an MRE if required.
Installed packages
Environment info
The text was updated successfully, but these errors were encountered: