On Thu, May 2, 2013 at 10:42 PM, Piyush 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--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 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 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 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@code.ros.org >>> https://code.ros.org/mailman/listinfo/ros-release >>> >>> >> > > _______________________________________________ > Ros-release mailing list > Ros-release@code.ros.org > https://code.ros.org/mailman/listinfo/ros-release > > -- William Woodall ROS Development Team william@osrfoundation.org http://williamjwoodall.com/