Hi all,<br><br>It&#39;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&#39;ve got the four ROS Utilities on the ROS_Packaging[1] wiki page done, and
 I&#39;m currently working through the 12 ROS Core packages.  I&#39;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.<br><br>There are a few issues I wanted to discuss:<br>1) ROS package naming and other packaging guidelines:<br>Right now we&#39;re using the name ros-%{rosdistro}-packagename based on Tom&#39;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&#39;ve moved /usr/etc/langs to /etc/ros-langs for the message generation subsystem)<br>

<br>2) Packaging Fuerte vs. waiting for Groovy:<br>Groovy is supposed to have significant changes to filesystem layout to make it more FHS friendly.  Based on my work with Fuerte, it&#39;s not too hard to beat Fuerte&#39;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.<br>

<br>3) EPEL<br>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&#39;t know how many IT departments rely on EPEL vs. the RH supported repos.  My inclination is that if it&#39;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. <br>

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

<br>Rich<br><br>[1] <a href="https://fedoraproject.org/wiki/SIGs/Robotics/ROS_Packaging" target="_blank">https://fedoraproject.org/wiki/SIGs/Robotics/ROS_Packaging</a><br>[2] <a href="http://rmattes.fedorapeople.org/rospackages/" target="_blank">http://rmattes.fedorapeople.org/rospackages/</a><br>