ROS Packaging Roadmap

[Rich Mattes]

Hi all,

It's been a little while since our last discussion about ROS packaging.  I
know I got bogged down with real life and dropped the ball with respect to
the f18 feature process work, but there has been some progress on that
front.  I've got the four ROS Utilities on the ROS_Packaging[1] wiki page
done, and I'm currently working through the 12 ROS Core packages.  I've
been stashing them on my fedorapeople page [2].  I think we can get at
least the core packages for ROS Fuerte done for f18 and then update them
all to Groovy once it comes out.

There are a few issues I wanted to discuss:
1) ROS package naming and other packaging guidelines:
Right now we're using the name ros-%{rosdistro}-packagename based on Tom's
initial packaging efforts.  Would it make sense to have a ros macro file
that defines things like %{rosdistro} vs declaring it in each package?
Additionally, since a lot of the ROS packages that come from github have
very similar structure, perhaps we can create a ROS package template, and
lay out guidelines for which virtual Provides to add to each package and
document where we deviate from the core ROS stacks (for example, i've moved
/usr/etc/langs to /etc/ros-langs for the message generation subsystem)

2) Packaging Fuerte vs. waiting for Groovy:
Groovy is supposed to have significant changes to filesystem layout to make
it more FHS friendly.  Based on my work with Fuerte, it's not too hard to
beat Fuerte's core packages into FHS compliance, so maybe we can focus on
getting the core stacks done for Fuerte and then once Groovy is out we
upgrade the core in f18+ and start reviewing additional well-known stacks
for groovy.

3) EPEL
Should we spend a lot of time targeting el6 (and even el5) as we are
packaging?  A lot of research institutions seem to be running redhat,
though I don't know how many IT departments rely on EPEL vs. the RH
supported repos.  My inclination is that if it's not too difficult, we
should try to at least support el6; el5 might be a bit harder due to the
lack of CMake 2.8 in the repositories.

In the meantime, I will submit rosinstall, rosdep, and rospkg for review
sometime this week since they're straightforward python packages which are
required by the upstream source installation directions (I've already got
vcstools reviewed and in Fedora).

Rich

[1] https://fedoraproject.org/wiki/SIGs/Robotics/ROS_Packaging
[2] http://rmattes.fedorapeople.org/rospackages/