Hi Bill, On Fri, 14 Dec 2018 22:52:46 +0100 Bill Allombert <[email protected]> wrote: > There is a circular dependency between libtf2-dev and > libtf2-geometry-msgs-dev: > > libtf2-dev :Depends: libtf2-geometry-msgs-dev > libtf2-geometry-msgs-dev :Depends: libtf2-dev > > Circular dependencies are known to cause problems > during upgrade between stable releases, so we should try to avoid them. > > See threads > http://lists.debian.org/debian-devel/2005/06/msg02111.html > http://lists.debian.org/debian-devel/2005/11/msg01101.html
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
signature.asc
Description: signature
