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

Fri May 3 05:42:02 UTC 2013

Hi Tully,

I really appreciate the detailed response. For the particular case of
libfreenect and libsegwayrmp, I'll try my best to summarize with my limited
knowledge on this problem.

1) I completely understand the concern about upstream packages being
diverged. From what I have seen on the OpenKinect mailing list, an upstream
release is unlikely as all the primary developers are busy with other work.
The issue has come up a couple of times in the last 6 months, but does not
go anywhere. The current system release is pretty dated, and does not suit
our requirements (USB 3.0 support, accessing multiple kinects by serial
number). If someone new decides to do a release, there is some chance that
it might diverge depending on what features they want in the system release.
2) A PPA is certainly feasible, though it means extra overhead that I would
very much like to avoid. At the same time, I am willing to go with this
option as a last resort.

It seems to me that the easiest solution for this problem would be one of
the following (based on what Jack suggested in his original email):
1) Make it mandatory to release a pkg-config file for a 3rd party package
while releasing through Bloom. If I am not mistaken, these packages can
then be treated as catkin dependencies. This would be similar to how 3rd
party packages were released through rosbuild in the past. At the same
time, this would allow distro specific 3rd party releases to be made with
the current infrastructure.
2) Embed distro resolution into rosdep, and resolve a ros-libfreenect
dependency as ros-<distro>-libfreenect. This would require changes to the
rosdep infrastructure. This should again allow for distro specific 3rd
party releases.

Thanks!
Piyush

On Thu, May 2, 2013 at 11:29 PM, Tully Foote <tfoote at osrfoundation.org>wrote:

>
> 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/20130503/499b791e/attachment-0009.html>