[Ros-release] Naming of 3rd-party packages

[Tully Foote]

So we have the capability to build non ros-DISTRO- prefixed debians.
 However we have been bit by this hard in the past and generally do not
recommend it.

A few examples from the past are yaml-cpp, openni*, and rosemacs-el.    We
had a "backports" release in which items were not prefixed with
ros-DISTRO-. You can see the remnants of that in the rosdistro repo [1]
 Bloom also has the ability to produce standard debians instead of "ROS"
debians.  So technically it's completely possible.

But we have run into some major issues with expectations of stability for
packages released this way.  One of the challenges is that if packages are
released without the ROS prefix they are required to be compatible with all
ros releases.

An example of this issue can be ween by looking at openni when a new
version came out which was not ABI compatible. Electric and Fuerte were
both well established using the old version, but people working in groovy
wanted the new version.  The upgrade was generally backwards compatible to
the public API so wouldn't break code.  Upgrading it required us to upgrade
it in all repositories at the same time, and rebuild all of electric,
fuerte, and groovy packages which depended on it simultaneously.   And this
is even worse as we build across several distros by default which ends up
with each ros distro expecting different versions of packages on the same
ubuntu distro.  So it took a huge effort to make that upgrade requiring all
packages in 3 distros to sync at the same time.  (This took ~ 2 weeks to
stabilize everything and make this one release. And all other releases were
held.) The lesson to be learned from this is that by stepping out of the
ROS prefix requires much higher levels of expected stability.

One good example of us doing this was providing yaml-cpp for lucid,
oneiric, and precise.  It was submitted upstream in quantal, but was not
backported by ubuntu maintainers.  We simply took that upstream package and
backported it.  This was valuable as it made it available to the ROS
ecosystem, but was specifically scoped not to collide with future releases.


I can not come up with a good example of this at the moment, but one
concern is whether packages are going to be submitted upstream.  And if
they do get submitted upstream, but are every so slightly different than
our version it can lead to major issues.  It's not specifically debian
packaging related, but we ran into this with bullet when we locally applied
patches and submitted them upstream.  The patches were valid but were
rejected as too disruptive for upstream, leaving the ROS bullet
implementation in limbo as it had now diverged from upstream.

Recently we've been following a different approach for openni as well as
collada-dom.  For these they each have PPAs in Ubuntu from upstream
providers.  [2] [3] We simply sync the already built packages into the ROS
repositories from the PPAs.  This has worked well for those packages.

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.

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.

Tully


[1] https://github.com/ros/rosdistro/blob/master/releases/backports.yaml
[2] https://launchpad.net/~openrave/+archive/release
[3] https://launchpad.net/~v-launchpad-jochen-sprickerhof-de/+archive/pcl

On Thu, May 2, 2013 at 5:56 PM, Piyush <piyushk at gmail.com> wrote:

> Just to add, I've run into the same problem while fixing the segway_rmp
> ROS package to depend on libsegwayrmp (3rd party package released through
> the ros build system). The only way I can release segway_rmp into bloom is
> adding a rosdep rule that resolves the rosdep libsegwayrmp to
> ros-groovy-libsegwayrmp.
>
> Any thoughts on this would be appreciated.
>
> Thanks!
> Piyush
>
>
> On Wed, May 1, 2013 at 9:38 AM, Jack O'Quin <jack.oquin at gmail.com> wrote:
>
>> Piyush Khandelwal and I recently used bloom to release a more
>> up-to-date version of libfreenect, with many important fixes that were
>> missing in the Ubuntu 0.2.1 version. We would like to remove it when
>> the upstream developers eventually release a newer version.
>>
>> Now, I am belatedly trying to understand how to resolve references to
>> packages like this. The rosdep database resolves "libfreenect-dev" to
>> the Ubuntu APT packages with the same name. But, our bloom package was
>> released as "ros-groovy-libfreenect".
>>
>> Rosdep is supposed to be ROS-distro-independent. This library is, too.
>> But, I don't know how to release it via the build farm under a
>> release-independent name.
>>
>> Is there a way to do that?
>>
>> Can I release "libfreenect-dev" via packages.ros.org? Or, is that a bad
>> idea?
>>
>> Should it be resolved like a ROS package, instead? It is not built
>> with catkin, will that be a problem? What are people building from
>> source supposed to do?
>>
>> What is the recommended solution for 3rd-party packages like this one?
>> --
>>  joq
>>
>
>
> _______________________________________________
> Ros-release mailing list
> Ros-release at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-release
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-release/attachments/20130502/afb2bc1c/attachment-0009.html>