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

Best practice for rosdep, ubuntu packages, and others

asked 2011-11-09 18:56:55 -0600

updated 2014-01-28 17:10:44 -0600

ngrennan gravatar image

Hello,

As already discussed in question #2701, I am working on the release of the modular_cloud_matcher package.

This package depends on libnabo and libpointmatcher, for which I provide Ubuntu packages for the last 4 releases (from Lucid to Oneiric) on my PPA. As there is currently no way to tell rosdep to fetch packages from a PPA, in a previous discussion with Tully Foote we agreed that the user will have to install these packages by hand.

The question then is whether I should add these as package dependency in the rosdep.yaml, and if so, what to do with non-ubuntu systems. Should I provide a script that fetches the packages and "cmakes/makes/makes install" them? If so, is there a way to provide an "other" or "default" target in rosdep.yaml? Or should I leave these dependencies out and let the user install libnabo and libpointmatcher by hand?

I will be happy to hear your opinion on the best practice in this context. Thank you!

edit retag flag offensive close merge delete

4 Answers

Sort by » oldest newest most voted
4

answered 2011-11-10 04:58:51 -0600

kwc gravatar image

We've been moving away from wrapping system-installable libraries in ROS packages. It leads to less portable code, as you end up using ROS-specific linking methods to use these libraries.

Instead, as much as possible, we are now trying to:

  • provide debs for these libraries on Ubuntu (we will hopefully make this toolchain available for packages.ros.org, but it still needs a lot of work)
  • provide an exemplar 'source rosdep' (REP 112) that is somewhat equivalent to the download_and_unpack-style builds, except they attempt to do system installs.

A valid criticism of source rosdeps is that they don't come with an uninstall mechanism. That said, the main role of the source rosdeps, IMHO, is to provide a starting point to people on other platforms. They are generally equivalent to what that user would have done if they had to manually download the source and install on their own.

We try to shy away from PPAs for libraries, as Ubuntu does, as they lack safety guards to prevent downstream issues.

edit flag offensive delete link more
2

answered 2011-11-09 20:19:02 -0600

Thomas gravatar image

Hi there!

I would recommend to create a ROS package for both libnabo and libpointmatcher until they become "first class" dependencies packaged on most of the major Linux distributions.

I recognize that it is preferable to have system dependencies over ROS dependencies, but do not forget that there is other Linux distributions that Ubuntu. What about the Fedora users for instance? They would still have to build and install your dependencies by hand.

The only other solution would be to use the ability in rosdep.yaml to put arbitraty shell code to download and build the package on non Ubuntu platforms. This is wrong for many reasons :)

Therefore, the only other solution is to package the dependencies as ROS packages. It is easy to do (look at https://github.com/laas/vision_visp/tree/master/visp">this for instance) and it will ensure that all ROS users will be able to use your package.

edit flag offensive delete link more
0

answered 2011-11-10 00:59:13 -0600

updated 2011-11-10 01:06:24 -0600

Hello!

Well, this is certainly one way, but it has some disadvantages: using distro packages allows to fix bugs and add API-compatible features (for instance new filters in libpointmatcher) without requiring a recompilation of the ROS package. The problem is that the reality of the research landscape is complex and that one often wants to use a lib with ROS in a project and as a standalone utility in another project. But I agree that providing only Ubuntu packages is not so nice. Fedora packages of libnabo and libpointmatcher would be very welcomed, but this is another question.

So I see three solutions:

  • Using rosdep.yaml to fetch and install the libraries in /opt/ros, possibly using apt-add-repository without rosdep.yaml on Ubuntu.
  • Providing a wrapper ROS package.
  • Using system package on Ubuntu and manual installation on other distros.

None of these solutions please me, as they all have major drawbacks.

Also, my question remains open: Is there a way to provide an "other" or "default" target in rosdep.yaml? Also it seems that rosdep's documentation is a bit outdated, for instance there is currently nothing in /opt/ros/lib or /opt/ros/include and ROS does not seem to use these locations.

edit flag offensive delete link more
0

answered 2011-11-10 04:01:29 -0600

Thomas gravatar image

updated 2011-11-10 04:02:16 -0600

I am not sure to understand too well your first solution but you could probably try something like:

rosdep_name:
  ubuntu: |
    sudo apt-add-repository <FIXME>
    sudo apt-get install <FIXME>

There is no default target in rosdep as it doesn't make sense when one uses it as it is intended to be. I.e. by filling package names and not executing shell scripts.

Additional note on my previous reply:

Of course I do not advise you to convert somehow your dependencies to full ROS packages (in the sense changing their buildchain or editing the package) but instead to use download_unpack_build.mk provided by rosmk. It retrieves an external package, build it separately, install it in a local prefix and consider it as a part of ROS.

I use several software as both standalone packages and ROS packages. Other projects such as PCL follow the same guideline.

As for applying local patches to fix bugs or add features, this is possible (download_unpack_build.mk supports it out of the box). By releasing your ROS stacks as Ubuntu binary packages, you can achieve updating without recompiling yourself. See the release process on the ROS wiki for more information on this.

Last thing: I do not like having to run apt-add-repository to install a software as this approach does not scale. If we end up having hundreds of PPA on a computer, the chance of breaking the packaging system at some point are really high.

edit flag offensive delete link more

Question Tools

2 followers

Stats

Asked: 2011-11-09 18:56:55 -0600

Seen: 979 times

Last updated: Nov 10 '11