[ros-users] Deb source packages

[Jack O'Quin]

On Mon, Jun 18, 2012 at 1:50 PM, Rich Mattes <richmattes at gmail.com> wrote:
> On 06/18/2012 03:48 AM, Tully Foote wrote:
>>
>> Hi Rich,
>>
>> Due to a long history of interweaved lineage PCL and ROS datatypes
>> collide.  We have not forked PCL as much as applied a patch to make it use
>> our generated messages instead of the stripped down versions built into PCL.
>>  This previously was done inside PCL upstream, however it has proven easier
>> to patch new releases than maintain the functionality within PCL.  Also it
>> does not require PCL to have anything ROS specific inside it's release.  The
>> git-buildpackages repositories allow us to reimport upstream and reapply our
>> patches on top of new releases as they come out.  If there is a patch
>> release to the version we have used we can take it up, and plan to.  We
>> cannot take up major API breaking releases.
>>
>> There has also been an initiative to release renamespaced versions of pcl
>> 1.6 as pcl16 as a backport into Electric.  I'm not sure of the current
>> status of that effort.
>>
>> Tully
>
>
> Hi Tully,
>
> Thanks for the reply.  I guess fork wasn't the best way to describe it, it
> is just a handful of files being added/modified on top of PCL's upstream
> releases.
>
> From a distribution maintainer's perspective, it would be nice to decouple
> the upstream PCL releases from ROS altogether.  Ideally, ROS would build
> against a stand-alone version of PCL without modification.  Since this is
> not an option due to the datatype interdependence, the next best thing would
> be to treat ROS as an optional dependency to PCL (it already partly is: PCL
> looks for ROS to determine whether or not it should use its included copies
> of sensor_msgs and std_msgs, or defer to ROS' copies.)   Since the
> interdependence is already there, it made sense to me to take the next step
> and include the ROS message headers for the point cloud messages as well
> (when USE_ROS was enabled), and that was the path I started to go down.
>  With that, as long as the message definitions don't change too much once a
> PCL release is made, you could lock ROS to depend on a specific version of
> PCL.  You could even going so far as to version the stack's name: pcl-1.5
> instead of pcl; this would also lend itself to creating explicit
> dependencies on newer backports, and letting API-compatible point-releases
> in without any modification.
>
> I understand that ROS development moves quite fast and isn't necessarially
> tied to anything the PCL guys are doing, so keeping a separate copy with the
> requisite modifications makes it easer to make modifications as ROS evolves.
>  Grabbing the latest changes from the wg repository for distribution
> packaging with ROS isn't the end of the world, and we can do that if it ends
> up being the best solution.  But if the messages and ROS stack info aren't
> changing that often, having PCL optionally treat itself as its own
> self-contained stack might be worth considering.

Problems with people trying to build PCL from source to run with ROS
are very common on answers.ros.org.

Their usual motives are:

 1) getting a more recent version than shipped with the ROS distro

 2) needing to fulfill the rosdep dependency on some non-Ubuntu system

We need a clear, well-documented method to accomplish that task.
-- 
 joq