Open alaurenzi opened 5 months ago
traversaro
commented
5 months ago 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 run_exports/run constraints. However, for sure @wolfv or @Tobias-Fischer may know more on this.
alaurenzi
commented
5 months ago 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-pkgUpdate: this environment can be solved and works fine (so far) Of course it is not ideal having to specify explicit versions
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) 
v4hn
commented
5 months ago ROS packages typically link against their dependencies using a soname that includes the whole version number down to the patch version.
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. Still, it does not change the fact that the relevant conda packages need to require the exact version of those upstream libs they were built with. Notice that the same problem was never explicitly solved in OR deb releases either. They simply rebuilt all downstream packages with each release anyway.
Tobias-Fischer
commented
4 months ago Hi @alaurenzi - many thanks for reporting this! This is indeed a problem that we should tackle. I think we should add run_exports to all packages and set the max_version to the patch version, so that the exact version is required to run. However, for this to work, we would need some way to capture all versions of all packages at a given point in time (https://github.com/RoboStack/robostack.github.io/issues/9). Otherwise, if there any package releases a new version, we might have to rebuild all packages which is not feasible currently.
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 ofros-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-corerequiringros-noetic-geometric-shapes==0.7.3, but havingros-noetic-geometric-shapes==0.7.5installed. 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