[ros-users] Deb source packages

[Rich Mattes]

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.

Rich