<div dir="ltr">Hi Tully,<div><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style>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.</div><div style><br></div><div style>
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):</div><div style>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.</div>
<div style>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. </div>
<div style><br></div><div style>Thanks!<br></div><div style>Piyush</div><div style><br></div><div style><br></div><div style><br></div><div style><br></div><div style><br></div><div style><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, May 2, 2013 at 11:29 PM, Tully Foote <span dir="ltr"><<a href="mailto:tfoote@osrfoundation.org" target="_blank">tfoote@osrfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><br></div>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. <div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div class="gmail_extra">Tully<br><br><br>[1] <a href="https://github.com/ros/rosdistro/blob/master/releases/backports.yaml" target="_blank">https://github.com/ros/rosdistro/blob/master/releases/backports.yaml</a></div>
<div class="gmail_extra">[2] <a href="https://launchpad.net/~openrave/+archive/release" target="_blank">https://launchpad.net/~openrave/+archive/release</a></div><div class="gmail_extra">[3] <a href="https://launchpad.net/~v-launchpad-jochen-sprickerhof-de/+archive/pcl" target="_blank">https://launchpad.net/~v-launchpad-jochen-sprickerhof-de/+archive/pcl</a></div>
<div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, May 2, 2013 at 5:56 PM, Piyush <span dir="ltr"><<a href="mailto:piyushk@gmail.com" target="_blank">piyushk@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="h5">
<div dir="ltr">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.<div>
<br></div><div>Any thoughts on this would be appreciated.</div><div><br></div><div>Thanks!</div><span><font color="#888888"><div>Piyush</div></font></span></div><div><div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, May 1, 2013 at 9:38 AM, Jack O'Quin <span dir="ltr"><<a href="mailto:jack.oquin@gmail.com" target="_blank">jack.oquin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Piyush Khandelwal and I recently used bloom to release a more<br>
up-to-date version of libfreenect, with many important fixes that were<br>
missing in the Ubuntu 0.2.1 version. We would like to remove it when<br>
the upstream developers eventually release a newer version.<br>
<br>
Now, I am belatedly trying to understand how to resolve references to<br>
packages like this. The rosdep database resolves "libfreenect-dev" to<br>
the Ubuntu APT packages with the same name. But, our bloom package was<br>
released as "ros-groovy-libfreenect".<br>
<br>
Rosdep is supposed to be ROS-distro-independent. This library is, too.<br>
But, I don't know how to release it via the build farm under a<br>
release-independent name.<br>
<br>
Is there a way to do that?<br>
<br>
Can I release "libfreenect-dev" via <a href="http://packages.ros.org" target="_blank">packages.ros.org</a>? Or, is that a bad idea?<br>
<br>
Should it be resolved like a ROS package, instead? It is not built<br>
with catkin, will that be a problem? What are people building from<br>
source supposed to do?<br>
<br>
What is the recommended solution for 3rd-party packages like this one?<br>
--<br>
joq<br>
</blockquote></div><br></div>
</div></div><br></div></div>_______________________________________________<br>
Ros-release mailing list<br>
<a href="mailto:Ros-release@code.ros.org" target="_blank">Ros-release@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-release" target="_blank">https://code.ros.org/mailman/listinfo/ros-release</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br></div>