-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Conversation
…ra-x86_64/orocos-kdl-devel-1.4.0-3.fc30.x86_64.rpm.htmlUbuntu: https://packages.ubuntu.com/xenial/liborocos-kdl-devDebian: https://packages.debian.org/source/buster/misc/orocos-kdlHomebrew: https://formulae.brew.sh/formula/orocos-kdlGentoo: https://packages.gentoo.org/packages/sci-libs/orocos_kdlSigned-off-by: Tully Foote <[email protected]> Signed-off-by: Tully Foote <[email protected]>
ubuntu: https://packages.ubuntu.com/focal/python3-pykdl debian: https://packages.debian.org/buster/python3-pykdl Signed-off-by: Tully Foote <[email protected]>
ubuntu: https://packages.ubuntu.com/source/focal/orocos-bfl debian: https://packages.debian.org/source/buster/orocos-bfl fedora: https://debian.pkgs.org/10/debian-main-amd64/liborocos-bfl-dev_0.8.0-5_amd64.deb.html Signed-off-by: Tully Foote <[email protected]>
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 on 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? |
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 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. |
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. |
* https://fedora.pkgs.org/30/fedora-x86_64/orocos-bfl-devel-0.8.99-17.20180529git3d0d149.fc30.x86_64.rpm.html * https://fedora.pkgs.org/30/fedora-x86_64/orocos-bfl-0.8.99-17.20180529git3d0d149.fc30.x86_64.rpm.html * https://fedora.pkgs.org/30/fedora-x86_64/orocos-kdl-1.4.0-3.fc30.x86_64.rpm.html * https://fedora.pkgs.org/30/fedora-x86_64/orocos-kdl-devel-1.4.0-3.fc30.x86_64.rpm.html Signed-off-by: Tully Foote <[email protected]>
* Add rosdep keys for orocos-kdl Signed-off-by: Tully Foote <[email protected]>
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 |
Re: ros-gbp/bfl-release#12
bfl rosdep keys:
ubuntu: https://packages.ubuntu.com/source/focal/orocos-bfl
debian: https://packages.debian.org/source/buster/orocos-bfl
fedora: https://debian.pkgs.org/10/debian-main-amd64/liborocos-bfl-dev_0.8.0-5_amd64.deb.html
python3-pykdl:
ubuntu: https://packages.ubuntu.com/focal/python3-pykdl
debian: https://packages.debian.org/buster/python3-pykdl
kdl keys:
Fedora: https://fedora.pkgs.org/30/fedora-x86_64/orocos-kdl-devel-1.4.0-3.fc30.x86_64.rpm.html
Ubuntu: https://packages.ubuntu.com/xenial/liborocos-kdl-dev
Debian: https://packages.debian.org/source/buster/misc/orocos-kdl
Homebrew: https://formulae.brew.sh/formula/orocos-kdl
Gentoo: https://packages.gentoo.org/packages/sci-libs/orocos_kdl
@sloretz @jacobperron We should look at not releasing bfl and kdl into ROS packages for Noetic and Foxy with these being available upstream now. @meyerj @smits Does that make sense?