ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

In general you can wrap up a 3rd party package into a ROS package but if there is one available upstream you should renamespace it or suppress all the symbols from escaping the package so as not to collide with the upstream one that may be in use by or more other packages.

The other option would be to conditionally compile the contents inside your package on the older platforms. It's usually easier to not expose the symbols this way.

In general our default position is to use the version packaged upstream. When there are different versions across the Ubuntu distros support you need to use ifdefs and the like to be dual compatible.

If the package is not released at all we can consider a backport of the newer versions as it won't conflict with the existing installation that doesn't exist. But since the older version already exists that won't work unless it can be shown to be compatible.

In this case I'd suggest considering building the library internally to your package on the older platforms and not exposing any of the symbols. And once Melodic has dropped support for Artful you can start relying on the upstream version in bionic if the version in stretch is up to date enough, or the stretch backports will work.

In general you can wrap up a 3rd party package into a ROS package but if there is one available upstream you should renamespace it or suppress all the symbols from escaping the package so as not to collide with the upstream one that may be in use by or more other packages.

The other option would be to conditionally compile the contents inside your package on the older platforms. It's usually easier to not expose the symbols this way.

In general our default position is to use the version packaged upstream. When there are different versions across the Ubuntu distros support you need to use ifdefs and the like to be dual compatible.

If the package is not released at all we can consider a backport of the newer versions as it won't conflict with the existing installation that doesn't exist. But since the older version already exists that won't work unless it can be shown to be compatible.

In this case I'd suggest considering building the library internally to your package on the older platforms and not exposing any of the symbols. And once Melodic has dropped support for Artful you can start relying on the upstream version in bionic if the version in stretch is up to date enough, or the stretch backports backports will work.