On Tue, Apr 9, 2013 at 9:55 AM, Ankur Sinha <sanjay.ankur@xxxxxxxxx> wrote:
Thanks! I'll have a look at those tonight. Now that catkin is done we can really get things moving.
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 that.
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.
Hi Rich,
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 that.
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.
Rich
_______________________________________________ robotics mailing list robotics@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/robotics
