Hi Bill,
thank you for your bugreport and for working on these issues!
Technically, we could indeed merge libtf2-geometry-msgs-dev into libtf2-dev.
But I would still like to talk about some alternative solutions. Let me explain
the situation.
Upstream is the ROS project. They use a sort-of package-manager called catkin.
As far as this package-manager is concerned, libtf2-dev and
libtf2-geometry-msgs-dev are two distinct packages. This is also why we decided
to make it two different binary packages: so that we mirror the granularity of
the upstream catkin packages in Debian. If we would now merge
libtf2-geometry-msgs-dev into libtf2-dev and let libtf2-dev provide
libtf2-geometry-msgs-dev, then this would have the following disadvantage:
For all our other ROS packages, users who need the foo_msgs catkin package
would just install the libfoo_msgs-dev Debian package. This would no longer
work in this specific case as libtf2-geometry-msgs-dev would only be a virtual
package and would thus be a surprise to the user. We'd like to avoid such
surprises.
The only way to avoid this that I can currently imagine would be to provide an
empty dummy package called libtf2-geometry-msgs-dev which would depend on
libtf2-dev (but not the other way round).
Do you see another way to solve this issue?
Unfortunately, both packages are shipping header files that include the headers
of the other and that's where the cycle is coming from.
Thanks!
cheers, josch