[ros-users] REP 122, REP 123, and REP 124: changes to ROS for ROS Fuerte

[Thibault Kruse]

Hi,

I want to explain more the issues with REP122 which REP122 already
mentions in the future work section.

(PREFIX in the following would by default be /opt/ros/fuerte.)
In fuerte, in non-legacy stacks the following changes are planned:
- stack folders lie immediately in PREFIX/share and do not contain their
packages
- package folders also lie in PREFIX/share, and do not contain all
their resources, but only the so called 'package-relative resources.
- ROS packages get installed without their source files.

An example of that would be the ros_comm stack and roscpp package that you
get if you install fuerte from aptitude today.

Electric:
$ rosls ros_comm
AUTHORS clients/ CMakeLists.txt Makefile messages/ roscore_migration_rules/
rosdep.yaml stack.xml test/ tools/ utilities/
$ rosls roscpp
bin/ CMakeLists.txt lib/ manifest.xml  msg_gen/ ROS_NOBUILD  src/ 
srv_gen/ cmake/ include/ Makefile msg/ rosbuild.cmake scripts/ srv/ test/

Fuerte:
$ rosls ros_comm
rosdep.yaml  stack.xml  stack.yam
$ rosls roscpp
cmake/  manifest.xml  msg/  rosbuild/  srv/

So the disk footprint is much smaller, but stacks and packages are barely
recognizeable.
With prior releases of ROS, a novice developer could do this:

$ roscd navigation; ls # to see the packages of a stack, and stack layout
$ roscd map_server; ls # to see the package layout
# inside the package:
$ vim/emacs/... include/map_server/image_loader.h # to see a relevant header
$ vim/emacs/... src/map_server.cpp # to see the source of the code that runs

This will all become more difficult with the currently planned setup
for future releases. Probably you all know students or researchers
from other fields who would have to learn a lot first to perform the
above steps without the stack/package layout ROS provides before
fuerte.

I believe that ROS should maintain the lessened learning curve to novice
developers by following these steps, without impact to the goal of being
FHS compliant:
1. installed packages are deployed into the folder of their respective stack
2. it should be easily possible to get all non-binary package-related
sources visible within their package folder
3. sources (e.g. cpp files) should be easily installable (and in
particular be installed using aptitude, e.g. $ aptitude install
ros-fuerte-navigation-src).

As a reason to install packages outside the stack folder REP122 states
that "we eventually wish for package-relative resources to be easily
located without ROS-specific toolchain such as rospack", however I
currently do not understand why we would want that, as opposed to wanting
to keep the stack/package hierarchy concept alive.

As mentioned in REP122, I referred to the stow tools behavior as a solution
for creating symlink based FHS compliance. However I do not advocate stow
as the ready-made solution, I only refer to the concepts of stow.
It should be possible to have all non-binary package relative resources
installed in PREFIX/share, and to use a tool like xstow to generate symlinks
for headers and scripts and python source files. If future ROS packages
were laid out like that, it is not clear whether ROS should impose that or
just suggest it.

More package related-resources including binaries could be deployed
with a stow-like solution, but it seems difficult to find an FHS compliant
location to stow from. 'share' would seem to not be allowed as any tools
should be able to rely on the assumption that contents of 'share' are
architecture independent.

The apt toolset provides a possible way to get package sources as a tar
file, but that is not the same easy user experience as having always the
same version of the source as the installed binaries even after updates.

So any input is welcome on how to maintain ROS stack and package cohesion
in the FHS world.

best regards,
  Thibault