ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
1

package.xml "provides"

asked 2015-02-10 13:49:13 -0600

dustingooding gravatar image

In version 2 of package.xml format, the "conflict" and "replace" tags are now available (yay). But what about the sibling "provides"? https://www.debian.org/doc/debian-pol...

Use case:

I make two packages, one that interacts with actual hardware (my_driver_real) and one that interacts with simulated hardware (my_driver_fake). Both implement the same interface, so dependent packages don't know or care which is used. But both can't be available on the same system, because they have the same file names (so they're interchangeable).

Ideally, I'd set both packages to "provide" an "interface name" (my_driver), as well as both conflict and replace. Then, a user can apt-get install my_driver_real, and if my_driver_fake is already installed it will be replaced. And other packages would simply (debian) depend on the "interface name", and as long as one of them was installed, all would be well.

Thoughts?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
4

answered 2015-02-10 14:31:39 -0600

William gravatar image

We explicitly did not support this as we do not support optional dependencies, but we have some reasons for not supporting it.

Consider this: You have package foo which depends on bar OR bar_faux using a provides "Bar" kind of thing. Then you run rosinstall_generator foo --deps, what does rosinstall_generator generate as the dependencies for foo? Does it include bar or bar_faux or both? Presumably bar and bar_faux cannot be installed at the same time, if they can, why not depend on both?

Another similar scenario: You have not released any of the aforementioned packages. You have checked out foo and bar_faux into a src folder. Then you ask rosdep to install dependencies for foo, does it install bar?

These are both example of how this feature would complicate the existing tools, but then there is packaging. This is where it is really problematic, consider: bar and bar_faux provide Bar, and foo depends on Bar, so when you are generating the .deb for foo you can handle that since apt has the mechanism to support it, but what about when you are packaging for Homebrew or Gentoo or anything which doesn't have that mechanism? You now have to look at all release packages and see which ones provide Bar and add them as explicit dependencies.

At that point you have to decide which one of the packages providing Bar should be directly depended on. The only way to do this, that I can imagine, is that one of the packages which "provides" Bar declares itself as the default. But then how do you handle if multiple packages do this or if no packages do this. The later could be because the default one has not been released yet.

By comparison replaces and conflicts can relatively safely be ignored by package managers which do not support it and do not complicate the toolchain significantly.


For the scenario you described, ROS is specifically designed for this case, but you should use multiple packages and a message interface to provide the abstraction not a "provides" mechanism.

You can have a package my_driver_msgs, which contains the interface, then a package which uses my_driver_msgs like my_driver_consumer which can either have a direct dependency on my_driver or my_driver_fake or both. Then your launch files will need to run one or the other. It's more of a composition, you might even have another package like test_my_driver_consumer which depends on my_driver_fake and gazebo or something which has a launch file which launches my_driver_consumer and my_driver_fake together.

Essentially we typically address this OR dependency in CMake or launch files.


With all of that being said, you can modify your debian/control file in the release process to do what ever you want. We're just not willing to support that mechanism across all of our tools and support platforms (current and future).

edit flag offensive delete link more

Comments

Good rationale. Thanks @William!

dustingooding gravatar image dustingooding  ( 2015-06-24 10:12:15 -0600 )edit

Question Tools

1 follower

Stats

Asked: 2015-02-10 13:49:13 -0600

Seen: 273 times

Last updated: Feb 10 '15