On Thu, May 2, 2013 at 11:29 PM, Tully Foote <tfoote@osrfoundation.org> wrote:
>
> So having said all that it's worth discussing how these concerns reflect on
> libfreenect.  The tools we have developed are definitely powerful and useful
> for those familiar with their deployment.  However, we don't want to take
> over building everything.

I suspected that releasing it without a ROS prefix would probably be a
bad idea. Your detailed explanation certainly confirms those worries.

I think our current ros-groovy-libfreenect approach will probably work
well enough. It does avoid most of the problems you mentioned. There
are difficulties, however.

> With what I know at the moment my recommendation would be to keep libraries
> which are being developed in the ROS ecosystem in the ROS prefix. And at the
> same time submit them for inclusion upstream in debian or ubuntu
> repositories. Once they are accepted there, we can switch the next ROS
> distro over to use the upstream packages, and if necessary backport the
> upstream packages into older Ubuntu distros to cover the spanning set for
> the ROS distro. This will prevent us from painful remerging issues in the
> future and provide flexibility to change things between ros distros if
> things change when submitted upstream.

We did not want to change the library, just pick up some fixes made
upstream but not released by them.

With catkin, there has been some blurring of the formerly clear
distinction between ROS dependencies and system dependencies. I doubt
I am the only one who gets confused when dealing with in-between
components like libfreenect. They probably need to be considered on a
case-by-case basis.

Based on their code and on what Piyush tells me, these upstream
developers are not particularly well-organized. I am reluctant to
gamble with tracking their development, but unwilling to fork the
project and maintain it ourselves. So releasing libfreenect with a ROS
prefix seems reasonable. Its main ROS user is the freenect_camera
driver. We maintain that package and can can modify it to resolve the
dependency as needed.

Still, there are difficulties. Taking an arbitrary 3rd-party package
and releasing it to function as a catkin dependency is not trivial.
Although libfreenect has a CMake build, it does not install things in
the places expected by catkin and ROS. It was putting libraries in
lib64/ and headers directly in include/. Moving the headers to
include/libfreenect/ forces incompatible changes to the library and to
its interface.

We are still learning how to use catkin_make_isolated, bloom and
jenkins to solve those problems. Catkin_make_isolated is confusing and
not well documented yet. We have had problems testing those kinds of
changes, but are gradually getting better at it. That has been
time-consuming.

Groovy presently has two ways to use libfreenect:

 * "libfreenect-dev" is a rosdep that resolves to the system package
with the same name.  Its headers are in /usr/include. It is missing
several important fixes needed for most ROS applications.

 * "libfreenect" is a "buildtool cmake" package that resolves to
ros-groovy-libfreenect. Its headers had to be moved to
/opt/ros/groovy/include/libfreenect, so the API is different.

I think this is confusing, but I don't know who might be using the
rosdep version. Should we delete the libfreenect-dev rosdep entry?
--
 joq