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

Fri May 17 20:24:31 UTC 2013

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

> 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.
>

It is already possible to release distro specific 3rd party packages in the
current infrastructure. 3rd party packages released according to REP-0136 (
http://ros.org/reps/rep-0136.html), which does not require a pkg-config
file, provide their own mechanisms for being found and used. There is
currently no need to diferentiate between catkin and non-catkin
dependencies.

The only reason to have a pkg-config is when you convert a package to third
party from rosbuild and want to be backwards compatible with other rosbuild
packages which depended on you previously.

> 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.
>

The preferred method is to release 3rd party packages according to REP-0136
for each ROS distro, and then people using those packages should refer to
the third party package's documentation on how to utilize them.

>
> 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
>>>
>>>
>>
>
> _______________________________________________
> Ros-release mailing list
> Ros-release at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-release
>
>

-- 
William Woodall
ROS Development Team
william at osrfoundation.org
http://williamjwoodall.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-release/attachments/20130517/af1410a7/attachment-0009.html>