The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
| | 2 | No.2 Revision |
Please see REP-003, specifically the sections for Kinetic and Lunar.
The ROS Kinetic and ROS Lunar installation pages also mention which Debian version they are compatible with.
Edit:
I would like to understand what policy exists (or doesn't exist) for ROS-Debian systems working alongside ROS-Ubuntu or ROS-Kinetic systems.
I only now notice this sentence in your question. I think you are referring to the results of the efforts in Debian Science/Robotics, correct?
I don't know about any policy, but as far as I know the packages in the Debian repositories are not the same as those supplied by the OSRF for Debian. So the ROS versions mentioned in REP-003 are not those that are part of Debian proper (or at least: are not those present in the officical Debian repositories). It is also not recommended to install ROS packages from both the ROS Debian repositories and the OSRF repositories, as binary compatibility is not guaranteed.
Refer to wiki/UpstreamPackages for more info on this.
| | 3 | No.3 Revision |
Please see REP-003, specifically the sections for Kinetic and Lunar.
The ROS Kinetic and ROS Lunar installation pages also mention which Debian version they are compatible with.
Edit:
I would like to understand what policy exists (or doesn't exist) for ROS-Debian systems working alongside ROS-Ubuntu or ROS-Kinetic systems.
I only now notice this sentence in your question. I think you are referring to the results of the efforts in Debian Science/Robotics, correct?
I don't know about any policy, but as far as I know the packages in the Debian repositories are not the same as those supplied by the OSRF for Debian. So the ROS versions mentioned in REP-003 are not those that are part of Debian proper (or at least: are not those present in the officical Debian repositories). It is also not recommended to install ROS packages from both the ROS Debian repositories and the OSRF repositories, as binary compatibility is not guaranteed.
Refer to wiki/UpstreamPackages (which is linked to from the Debian install pages on the ROS wiki) for more info on this.
| | 4 | No.4 Revision |
Please see REP-003, specifically the sections for Kinetic and Lunar.
The ROS Kinetic and ROS Lunar installation pages also mention which Debian version they are compatible with.
Edit:
I would like to understand what policy exists (or doesn't exist) for ROS-Debian systems working alongside ROS-Ubuntu or ROS-Kinetic systems.
I only now notice this sentence in your question. I think you are referring to the results of the efforts in Debian Science/Robotics, correct?
I don't know about any policy, but as far as I know the packages in the Debian repositories are not the same as those supplied by the OSRF for Debian. So the ROS versions mentioned in REP-003 are not those that are part of Debian proper (or at least: are not those present in the officical Debian repositories). It is also not recommended to install ROS packages from both the ROS Debian repositories and the OSRF repositories, as binary compatibility is not guaranteed.
Refer to wiki/UpstreamPackages (which is linked to from the Debian install pages on the ROS wiki) for more info on this.
Finally: compatibility between ROS node graphs running across multiple machines with some of these nodes coming from OSRF and others from the upstream Debian pkgs is also not guaranteed, but in practice could work. Exchanging messages and invoking services should work, provided that message and service definitions haven't changed. For most of the core this has been the case for quite some time, so I would expect upstream and OSRF provided ROS pkgs to be compatibility across msg/svc boundaries.
| | 5 | No.5 Revision |
Please see REP-003, specifically the sections for Kinetic and Lunar.
The ROS Kinetic and ROS Lunar installation pages also mention which Debian version they are compatible with.
Edit:
I would like to understand what policy exists (or doesn't exist) for ROS-Debian systems working alongside ROS-Ubuntu or ROS-Kinetic systems.
I only now notice this sentence in your question. I think you are referring to the results of the efforts in Debian Science/Robotics, correct?
I don't know about any policy, but as far as I know the packages in the Debian repositories are not the same as those supplied by the OSRF for Debian. So the ROS versions mentioned in REP-003 are not those that are part of Debian proper (or at least: are not those present in the officical Debian repositories). It is also not recommended to install ROS packages from both the ROS Debian repositories and the OSRF repositories, as binary compatibility is not guaranteed.
Refer to wiki/UpstreamPackages (which is linked to from the Debian install pages on the ROS wiki) for more info on this.
Finally: compatibility between ROS node graphs running across multiple machines with some of these nodes coming from OSRF and others from the upstream Debian pkgs is also not guaranteed, but in practice could work. Exchanging messages and invoking services should work, provided that message and service definitions haven't changed. For most of the core this has been the case for quite some time, so I would expect upstream and OSRF provided ROS pkgs to be compatibility across msg/svc boundaries.
Edit 2:
Ok, so Stretch's repos point to Lunar; thanks
Re-reading your comments - and interpreting them in the context of my first edit: I don't think you can conclude that from REP-003. The only thing that REP documents is the set of supported OS for which packages are being built by the OSRF buildfarm. Those packages are not contributed upstream, and are only available from repositories.ros.org. Those packages are usable on Debian Jessie (Kinetic) and Stretch (Lunar), but are not the same as those provided by upstream Debian.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
