orocos / orocos_kinematics_dynamics

Orocos Kinematics and Dynamics C++ library
679 stars 407 forks source link

Any plans for ROS noetic release? #408

Closed gaya- closed 2 years ago

gaya- commented 2 years ago

Thanks a lot for maintaining this library!

I was wondering if you have any plans to release the packages with bloom and put them up onto the ROS build farm? If you don't have experience with bloom-release, I could help or even do the release myself, provided access to your release repo.

MatthijsBurgh commented 2 years ago

I am open to that.

@smits @meyerj you have more experience with this. Do you see any issue doing this?

meyerj commented 2 years ago

This is a recurring topic (https://github.com/orocos/orocos_kinematics_dynamics/issues/348). It has been decided by the ROS maintainers at OSRF that KDL is not to be released into Noetic and that the version released into Debian/Ubuntu or the respective OS version will be used instead (http://wiki.ros.org/noetic/Migration#Use_Orocos_KDL_and_BFL_rosdep_keys). So there is no ROS noetic release of Orocos KDL today.

There are basically two options now to bring a new version into the ROS ecosystem for the most common Ubuntu 20.04 Focal/ROS Noetic ecosystem:

  1. Release a newer version of 1.4 into Debian (source package orocos-kdl)

    • It needs to be ABI compatible, and no significant changes like the switch from SIP to pybind11 should be applied, I guess. See here for the fork that the Debian build system is using. The version on branch release-1.4 is probably closest to a release, but also not up-to-date with the laster master.
    • I have no idea at the moment how we can trigger such a release, or become a Debian maintainer. The Debian maintainer is @jspricke and others.
  2. Revisit the decision from https://github.com/orocos/orocos_kinematics_dynamics/issues/218#issuecomment-596007427?

    • That may require changes in other packages, too, because the rosdep key was changed to liborocos-kdl-dev. So that key should probably be kept to point to the system version, but perhaps another, newer version could be released additionally in ROS as long as it does not conflict (different include directory) and can be selected deliberately by package maintainers by using another ROS key. However, that tends to be error-prone...
jspricke commented 2 years ago

@gaya-: for which distro/version do you need it?

@meyerj: Ubuntu 20.04 stopped importing from Debian sometime in 2020 so there is no need to get a new version into Debian. Apart from that, Debian testing/unstable has version 1.5.1: https://tracker.debian.org/pkg/orocos-kdl. In general we only import tagged releases, not a random master. If there are important fixes for the 1.4 series we could also import them into the OSRF distribution with the orocos-kdl package, there is no need to use bloom or even change the rosdep key.

gaya- commented 2 years ago

@gaya-: for which distro/version do you need it?

Ubuntu 20.04.

This is a recurring topic (#348).

Oh sorry, my bad. I only searched in open issues and not the closed ones.

It has been decided by the ROS maintainers at OSRF that KDL is not to be released into Noetic and that the version released into Debian/Ubuntu or the respective OS version will be used instead.

I see. We're only using the Python wrapper, so if I can import the library out of the box with python3-pykdl in the package.xml, that would be sufficient for us. The only problem would be backwards compatibility, as our software works on Ubuntu 16.04, 18.04 and 20.04 from the same repo branch and I'd like to keep it that way. But maybe there are some smart condition tags in package.xml or I could do some cmake / scripting magic.

gaya- commented 2 years ago

Ok, so I did this to my package.xml:

<?xml version="1.0"?>
<?xml-model
  href="http://download.ros.org/schema/package_format3.xsd"
  schematypens="http://www.w3.org/2001/XMLSchema"?>
<package format="3">

...

  <exec_depend condition="$ROS_DISTRO != noetic">python_orocos_kdl</exec_depend>
  <exec_depend condition="$ROS_DISTRO == noetic">python3-pykdl</exec_depend>

...

and all is good now. From my perspective, this issue can be closed. And maybe you can put a hint to this in your README.md or so, such that people stop asking :)