On Tue, Apr 9, 2013 at 9:55 AM, Ankur Sinha <sanjay.ankur(a)gmail.com> wrote:
I've approved catkin and reviewed a few other ros related packages. I've
picked up ones that aren't dependent on others. I'll go up the dep tree
from these leaf nodes.
Thanks! I'll have a look at those tonight. Now that catkin is done we can
really get things moving.
I was just wondering if we're going to name the packages ros-fuerte-XXX
or not? The current packages are all just python-XXX or just XXX. We'll
have quite a lot of trouble if we do groovy later, won't we?
My thinking was to not do fuerte and groovy as parallel installable in the
core OS, since sharing /usr/share on the ROS_PACKAGE_PATH would be a giant
mess. Instead, I was thinking we would have one supported rosdistro for
each Fedora. Currently it looks like Fedora 18 and 19 will have fuerte,
and we can work on upgrading rawhide to groovy (or hydro once it ships)
before Fedora 20 is released. We could probably make the case to upgrade
Fedora 19 to groovy post-release, but I'd prefer not to since it's such a
giant change. That my mean we jump from fuerte to hydro, but I'm ok with
I've been naming the ros modules according to what I think the packaging
guidelines dictate because of the above, but the current use of python-xxxx
vs ros-xxxx vs xxxx is definitely up for debate. Basically, if something
only contains python modules I try to name it python-xxxx. If something
has a uselessly generic name (like "std_msgs"), I name it ros-xxxx to avoid
confusion. Other than that, I just stick with the upstream stack name
(which usually contains ros somewhere in it anyway.) I'm creating a
virtual Provides: for ros-stackname for every package anyway, so "yum
install ros-*" will do the right thing. Once ROS is packaged, we can
create a comps.xml group for it, or add it to the "robotics" comps group.
In parallel, I think we should take an approach similar to Willow Garage
for supporting other rosdistros. Namely, creating packages that dump the
stacks to /opt/ros/<rosdistro>, but using system dependencies wherever
possible. This is the approach I started with the ros-fuerte copr I
started. I'm also using the ros-<rosdistro>-<stackname> for all of those
packages so you can yum install ros-fuerte-* and get the packages that
install to /opt, and they won't overlap or conflict with the fedora
supported ros in /usr.
Btw, I've been trying to build groovy on my f18 from source. I build the
base and the ros-desktop stack, but I'm not sure how well it works. I
couldn't get gazebo to work when I compiled it in ROS style.
I had to modify Gazebo's setup.sh script to locate OGRE's shared libraries
properly when I created the Fedora pacakge, maybe there's some of that
configuration that you're missing. ROS doesn't understand /usr/lib64; a
lot of problems stem from there.