[Ros-release] rosdep updates for Fuerte releases

Ken Conley kwc at willowgarage.com
Tue Mar 20 17:07:14 UTC 2012


2012/3/20 Stéphane Magnenat <stephane.magnenat at mavt.ethz.ch>:
> Hi,
>
> Ok, I can answer myself by reading carefully:
>  http://www.ros.org/wiki/release/Releasing/fuerte
> So the rosdep.yaml must be contributed upstream.
>
> I have a question related to contributing hardware-related dependencies:
> asebaros 0.8.0 depends on libhal and more recent versions on aseba depend on
> libudev on Linux, and other packages on OS X and Windows. In the current
> rosdep.yaml inside ethzasl_aseba, I have a serial_port dependency. Should we
> keep something like this? Is there a best practice to address meta-packages
> that have different dependencies on different platforms?

I'd prefer to not have meta-packages because they assume that one
library's cross-platform approach is the same as another.  If they
aren't, then you get multiple rosdep keys referring to the same system
dependencies, which is a state we'd ideally avoid.

Another approach, for example, is to simply provide empty definitions
for platforms that the rosdep key is impossible on.  Then, your
library depends on all of the specific system dependencies, but only
one has an active definition for a particular platform.

The downside of this alternative is that installation of libudev
'succeeds' on other platforms.

Yet another alternative is to figure out how to extend the rosdep
syntax to express these sorts of union rules.  The logic could get a
little tricky, but haven't really thought it through.  I'm more in
favor of the empty rule approach -- at worst, it enables rosdep to
succeed on an unsupported platform, which will then be followed by a
build that fails.  The end result is the same: the library doesn't
build on an unsupported platform.

 - Ken

>
>
> Kind regards,
>
> Stéphane
>
> --
> Dr Stéphane Magnenat
> http://stephane.magnenat.net
> _______________________________________________
> Ros-release mailing list
> Ros-release at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-release



More information about the Ros-release mailing list