Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add rosdep rules for orocos kdl and orocos bfl #23841

Merged
merged 5 commits into from
Mar 9, 2020
Merged

Conversation

@tfoote tfoote added the rosdep Issue/PR is for a rosdep key label Feb 21, 2020
@tfoote tfoote requested a review from a team as a code owner February 21, 2020 19:41
@meyerj
Copy link
Contributor

meyerj commented Feb 21, 2020

I was not aware that KDL was packages for all those distributions. It seems like the right way to go, but on the other hand I would not know the process or how long it takes to get a bugfix release in all distributions. Taking into account that KDL is quite stable and there is not a lot of activity (at least not from the maintainer's side), it is probably okay to transition to upstream releases.

What does that mean for packages that currently depend onorocos_kdl? Would all the manifests require an update then? Or could the rosdep key orocos_kdl not point to the respective upstream packages starting from Noetic? I don't like the fact that sometimes different source branches need to be maintained per ROS distro because of those small differences, although the actual code could be exactly the same (e.g. for Gazebo before ros-simulation/gazebo_ros_pkgs#473).

I will check in the coming days how the different versions compare, how much they lack behind the current master branch and which pending pull requests could be merged before another 1.4 release. But if the KDL release is blocking you and the upstream versions work, feel free to go on. I assume that if something would break along the way, the decision could still be revised until the Noetic release?

@tfoote
Copy link
Member Author

tfoote commented Feb 21, 2020

how long it takes to get a bugfix release in all distributions.

To set the expectation for this, don't expect bugfixes to get propagated. In general once things are in the distro after release they're effectively static.

Since KDL is quite stable now I hope that we're ready to do this transition.

The challenge with overlaying our packagest if there's upstream packages, it's very hard to coexist. Think of very nasty linking problems because you accidentally end up linking against the system version which is just slightly different. For many of our core packages we have to end up setting conflicts and replaces rules as well as make sure that our version numbers are strictly higher than the upstream ones. On the flip side projects and tools upstream that depend on the system version may have problems working in the ROS workspace if we have a slightly newer version.

In general as long as there's not any critical issues with the version upstream I'd suggest we should work with that version. We'll be a little bit behind the latest, but we'll be that way anyway. If there's a super critical bugfix we could roll our own patched version of the upstream package that's ABI compatible and add it to our repositories.

Also if you identify anything missing from the focal version, it's still in the prerelease and we could work with the debian/ubuntu maintainers to get patches into that before the release. @j-rivero FYI.

We can make the decision up until the noetic release but it really needs to be noteably sooner as all downstream packages will need to change their dependencies to point to the rosdep key instead of the pure package dependency or vice versa. The new package.xml has support for conditional dependencies so you don't have to branch development to support the change. That's of course assuming the code is the same and it's just the packaging.

@j-rivero
Copy link
Contributor

Also if you identify anything missing from the focal version, it's still in the prerelease and we could work with the debian/ubuntu maintainers to get patches into that before the release. @j-rivero FYI.

We are only 3 days away of closing the Focal autosync from Debian and after that, getting changes into Ubuntu will be harder. It is probably too late for something touching the API/ABI but small we can give a try for small patches.

@tfoote tfoote merged commit 3a655fc into master Mar 9, 2020
@tfoote tfoote deleted the tfoote/orocos_rules branch March 9, 2020 22:54
@ros-discourse
Copy link

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/updates-on-orocos-ros-1-and-2-integration/15146/13

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rosdep Issue/PR is for a rosdep key
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants