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 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 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@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > >