[ros-users] Packaging Ros: a nightmare?

[William Woodall]

I am cc'ing the ros-sig-buildsystem mailing list, we should continue the
discuss there and not pollute ros-users.

I think that fact that bloom is designed to generate debains that are not
specific to ubuntu is kind of the point.  If the generated debians are not
compliant or the underlying software is not FHS compliant, then we need
specific problems reported so we can fix them.

Our goal _is_ to eventually get ROS into debian/ubuntu by default.  Towards
that we are trying to build more compliant debians from catkin projects.
 If bloom is not producing compliant debians, we want to fix that.  If
dependencies are not getting resolved correctly then they need to be
updated in the rosdep database.

More specifically:

On Thu, Oct 18, 2012 at 2:24 PM, Jochen Sprickerhof <
ros-users at jochen.sprickerhof.de> wrote:

> Hi William,
>
> Thanks for the infos, but that's actually not the point. In fact I can
> install ros-groovy-perception-pcl and it's dependencies without problems
> on my Debian sid using Ubuntu as an extra repository. The problem is,
> that the PCL version in ROS is not integrated into the filesystem


You mean ros-groovy-pcl is not FHS compliant because of the /opt/ros/groovy
install prefix?  If so, bloom's 'debian' generator (as opposed to its
'rosdebian' generator) will generate a pcl debian with an install prefix of
'/usr/local/' no problem.  PCL itself is FHS compliant as far as I can
tell.  If not "integrating into the filesystem", means the /opt/ros/groovy
prefix, then that is a feature so that multiple versions of ROS (and PCL)
can be installed side by side.  Is installing to /opt/* not a valid option?


> and
> the package is not split into lib, bin and dev packages,


This is planned: https://github.com/ros/bloom/issues/32, at least for
runtime, dev, debug, and doc.  To support this dependencies in catkin must
be declared as run, build, build_tool, or test type dependencies.


> meaning that I
> need to change my installed boost development version for example.


Why? It seems to me that you would need to compile against the same
development version of boost that pcl was compiled against. The goal is to
ship debians built against the official version of boost for the target
system, if the debian for pcl is depending on the wrong version of boost
for a given distribution then that is due to an incorrect rosdep rule and
it should be updated.  If you are using a manually installed, newer version
of boost, then there is not much to be done about that, short of you
recompiling your debians against the newer version of boost.


> Next
> the dependencies are wrong, so the package depends on
> libboost1.46-all-dev instead of the specific libs,


This is set by the PCL developers and the related rosdep keys, it should be
brought to their attention if it is wrong.


> so I guess
> dh_shlibdeps, which would automatically add the right dependencies, is
> disabled.


I am not familiar with how this works, but I am open to using it if it will
help.  I don't know why it was disabled in the first place, this is where
we could use some input from more experience debian packagers.


> If you want to see how it could be done, have a look into the
> Debian dir from my PPA version (note that I'm not an official Debian
> developer, so I can't give final answers here).
>

I'll check it out.  Now that we have something working with catkin (bloom
0.2), we can start to refine the catkin->debian generator and make it more
compliant.


>
> Sorry for hammering on this, but I would really like to see ROS in
> Debian and Jack you are absolutely right, I should join the list, only
> that I don't want to get involved into that to much because of time
> constraints ;).
>

We appreciate any time you could spend reviewing the current system and
making concrete suggestions with regards to the packaging.


>
> Cheers Jochen
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>



-- 
William Woodall
Willow Garage - Software Engineer
wwoodall at willowgarage.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20121018/322c4255/attachment-0004.html>