<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 style>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 style><br></div><div style>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 style><br></div><div style>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 style><br></div><div style>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 style><br></div><div style>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 style><br></div><div style>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 style><br></div><div style>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 style><br></div><div style>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 style><br></div><div class="gmail_extra">Tully<br><br><br>[1] <a href="https://github.com/ros/rosdistro/blob/master/releases/backports.yaml">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">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">https://launchpad.net/~v-launchpad-jochen-sprickerhof-de/+archive/pcl</a></div>
<div class="gmail_extra"><br><div class="gmail_quote">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><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 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 class=""><font color="#888888"><div>Piyush</div></font></span></div><div class=""><div class="h5"><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>_______________________________________________<br>
Ros-release mailing list<br>
<a href="mailto:Ros-release@code.ros.org">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>