0

I am creating a package that depends on the ROS package ros-noetic-moveit-core. More specifically, it contains a shared library linking against libmoveit_robot_model.so.

libmoveit_robot_model.so is i a symbolic link to libmoveit_robot_model.so.1.1.7, so libmoveit_robot_model.so.1.1.7 ends in the NEEDED section of my shared library.

However, when I package it, dpkg-shlibdeps only adds ros-noetic-moveit-core to the shlibs depends, without any version information.

When MoveIt! update to a newer version, like it did when updating from 1.1.6, the library libmoveit_robot_model.so.1.1.7 will be replaced by libmoveit_robot_model.so.1.1.8 (for example), and my package will no longer link, while dpkg do not see the conflict.

How can I make sure that my package correctly inform of its dependencies? I see two solutions:

  • Find a way to not include the version suffix when linking so my package is compatible with multiple version of MoveIt!, but I do not like this solution (especially since MoveIt! do not provides a symbols file or event a symbolic link with a major version suffix, like libmoveit_robot_model.so.1).
  • Find a way to make dpkg-shlibdeps find the used version of MoveIt! so my package is upgraded alongside MoveIt!.

If it is an error from the MoveIt! packager, what can they do, and what can I do while waiting for the packages to be fixed?

More information on MoveIt!:

  • I am using this .deb package.
  • There is no .symbols file.
  • The file /var/lib/dpkg/info/ros-noetic-moveit-core.shlibs contains the following:
#... libmoveit_robot_model 1.1.7 ros-noetic-moveit-core #...
Improve this question

1 Answer 1

Reset to default
2

This is indeed a packaging problem (and arguably, a library definition problem). Before I get to that, here’s what you can do to fix it: you can specify your own shlibs line, either in debian/shlibs.local in your package’s source code, or in /etc/dpkg/shlibs.override. Add a line of the form

libmoveit_robot_model 1.1.7 ros-noetic-moveit-core (>= 1.1.7), ros-noetic-moveit-core (<< 1.1.8)

to tie your package to 1.1.7 versions of the ros-noetic-moveit-core package.

As for ros-noetic-moveit-core itself, it should ship its libraries in a package whose name reflects the package’s soname. If each version of the package isn’t backwards-compatible, then that name should include the full version (so it’s repeated, in the package name as well as its metadata). If versions 1.1.8 is supposed to be a drop-in replacement for 1.1.7, then the soname should stop at 1.1 or even 1. The relevant chapter of Debian Policy, which describes best practices relevant not only for Debian, is the chapter on shared libraries. This footnote gives a command to calculate the appropriate package name for a library.

Improve this answer
2
  • Thanks! Isn't there a debhelper tool for them (or me) to generate a correct shlibs file? Commented Feb 1, 2022 at 14:25
  • Found it, It's dh_makeshlibs. Also, bloom (ROS and MoveIt! packaging tool) has an issue on this: github.com/ros-infrastructure/bloom/pull/426 Commented Feb 1, 2022 at 14:31

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.