[ros-users] Alternative package dependencies

[Ken Conley]

In order to produce a normalize ROS debian package as well as
standalone message libraries, we are transitioning to using a pure
CMake infrastructure (i.e. sans rosmake).  As part of this, we are
also considering making manifest.xml optional as it becomes somewhat
superfluous -- there's no build information to encode as that is all
handled within CMake.  This would have the additional affect of making
unary stacks less klunky as only a stack.xml would remain.  This is
still in the idea phase, though Troy is putting together a design
document as we continue to get all the various jigsaw pieces to fit
together.

NOTE: the above would not eliminate rosmake; it just means that
lower-level dependencies would be transitioned to having proper
install targets and being built against as you would any other
rosdep-like dependency.

This is a long way of providing background on how to specify optional
dependencies.  On the build side, part of the answer would be that the
logic would all be contained within the CMake file.  On the release
side (i.e. stack.xml, rosdep.yaml, and debbuild), the question is what
is beneficial to provide? The intent of the rosdep dependencies is to
automate the process of installation.  The boolean logic spec provides
for a set of solutions but does not suggest which solution to choose,
which is problematic.

 - Ken

On Fri, Nov 18, 2011 at 1:22 PM, Patrick Mihelich
<mihelich at willowgarage.com> wrote:
> My initial reaction was, "This way lies madness," but apparently there is
> some precedent for this feature in package managers. From the Debian Manual:
>
>> In the Depends, Recommends, Suggests, Pre-Depends, Build-Depends and
>> Build-Depends-Indep control fields of the package, which declare
>> dependencies on other packages, the package names listed may also include
>> lists of alternative package names, separated by vertical bar (pipe) symbols
>> |. In such a case, if any one of the alternative packages is installed, that
>> part of the dependency is considered to be satisfied.
>
> So maybe it is interesting to look at how this feature is used in deb
> packages, and maybe rosdep for Ubuntu/Debian could piggyback on that
> feature. I'm not sure what you'd do for other package managers that don't
> natively support this. All that would need to be precisely specified.
>
> The "&&" behavior I think is more usually implemented as a virtual package
> or by simple dependencies (e.g. PyQt bindings for OpenGL would already
> depend on PyQt bindings right?).
>
> As always when making core stuff more complicated, make sure to ask, "How
> badly do we really need this feature?" Is it so awful if the user ends up
> with redundant packages installed?
>
> Cheers,
> Patrick
>
> On Fri, Nov 18, 2011 at 11:31 AM, Dirk Thomas <mail at dirk-thomas.net> wrote:
>>
>> Hi,
>>
>> while working on the ROS GUI SIG we think we found certain features to be
>> missing for the ROS package dependency mechanism.
>> We have a package which needs at least one of two specific dependencies in
>> order to work (i.e. PyQt binding or PySide bindings).
>>
>> Specifying both dependencies would be bad as some users might not want to
>> install both bindings (since either one would be sufficient).
>> Specifying no dependency would lead to a package which does not work if no
>> bindings are available at all (making the dependency checks useless).
>>
>> What we would need is to specify that the package has the dependency A
>> "or" B.
>>
>> Actually A and B might even consist of multiple packages (i.e. A would be:
>> PyQt bindings + PyQt bindings for OpenGL + whatever).
>> So it might be necessary to specify dependencies like:
>> (A1 && A2 && A3) || (B1 && B2)
>>
>> What are your thoughts on this?
>> Is this already possible, or would it be a feasible enhancement?
>>
>> Dirk
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>