Presently ROS has packages for Ubuntu and a source distribution for everyone else. I'd like to put together a package for my distro (archlinux) so I can install it across multiple computers efficiently.
Are there best practices for this? For a system installation of ROS? Are there packaging scripts that can be referenced or modified to support other packagers?
It appears that in ROS, each package has dependencies that are a mix of ROS packages and distribution packages; and that some ROS packages exist only because Ubuntu does not distribute the correct version for ROS.
Other distributions will have a different combo of package versions. They might be missing a version that Ubuntu has (thus wanting ROS to build the correct version from source) or they might have the correct version where Ubuntu did not.
How do I determine the expected (package) version of each package dependency?
rosdep is the cross-platform tool for managing how system dependencies are installed. It contains support for Arch, though I'm not sure how well used it is.
That said, the problem noted has some incorrect assumptions:
"I just spent a day installing ROS and watching it's dependency system compile a pile of software that's already installed in my system (PCL, Gazebo, orocos, etc)."
Each release of ROS requires a very specific version of PCL, Gazebo, Orocos, etc... ROS recompiles its own versions so that everything works together. You might not get very far attempting to compile against your own system installed versions of these libraries as PCL and Gazebo have non-backwards-compatible API changes in recent releases.
Starting in ROS Fuerte, PCL and OpenCV are treated as system dependencies via rosdep, which means that you could attempt to start using rosdep in this way. In Groovy, Gazebo will likely get the same treatment. However, you will probably quickly find, as joq notes, that it takes much more time than you think to save disk space.
EDIT: in response to the updated question, my answer remains the same. If ROS builds it, you should build it as well. Only dependencies modelled by rosdep can be substituted with your platform's system dependencies. The version to use is "If ROS builds it from source, use that version. If ROS treats it as a rosdep, look at the rosdep.yaml database and pick whatever version is closest on your platform."
Starting in ROS Fuerte, many of the lower level stacks are close to FHS compliant, and thus easy to repackage for other distributions. As for system dependencies that are repackaged in ROS, you simply cannot substitute system dependencies for them due to the way the build system works (and there are often patches that you need). The goal is to eliminate most re-packaged system dependencies when Ubuntu Precise is available, so this will be much improved by the ROS Groovy release.
Currently a ROS installation looks like a source based install, just that it resides in system wide paths (e.g. /opt/ros/electric). Installation packages are usually on a per-stack basis. The reason for compiling software like pcl might be that ROS is using another version then the system install.
That being said, please have a look at REP 122 ff as the installation layout will change dramatically for fuerte looking more like a "normal" system package.
I'm an arch user as well, and since I didn't want to package ROS myself, I just took the ubuntu packages, and built a PKGBUILD around it. I made it for the current ros-electric-base version 1.0.0, but I suppose you could do something similar for furte or the desktop packages.
The PKGBUILD does a bit more than installing the files that are contained in the *.deb files, such as:
You'll find the necessary files following the links below. Just place the files in a folder in your abs-directory and call makepkg. The resulting package (*.tar.xz) can be installed with pacman -U <packagename>.
Asked: Feb 22
Seen: 210 times
Last updated: Mar 20
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
ROS evolves rapidly. Understand that maintaining this is going to be a significant long-term commitment.
joq (Feb 22)edit