Transitively depending on something is an anti-pattern, but as this situation (ie: cpp_common brining in all of libboost-dev-all) has existed for so long there is a good chance it’s actually quite common. The Noetic changeover would be a good time to break things in this case.
It would allow us to gauge potential positive sides of this effort without immediately breaking everything.
But if we’re targetting Noetic I would be OK with not doing this.
I do expect there to be a rather large set of packages that will not have (active) maintainers any more (see the Orphaned Package maintainer effort fi) and releasing packages into Noetic could become a bit more of a hassle if we start pruning build and exec depends.
I don’t have deep knowledge in this area, but my impression is that Debian packaging sidesteps much of this need by generating a lot of the runtime dependencies automatically. So like, you cast a wide net at build time with something like Build-Depends: libboost-dev, but then dpkg-shlibdeps steps in and examines the linker information for the binaries you produced and only generates runtime dependencies for the stuff you actually need. And similarly, runtime deps for Python packages are generated from the info already in the setup.py file rather than duplicated.
So like, the only runtime deps which must be explicitly stated in the control file are the oddball cases where you’re doing something not visible to ldd, like invoking a process or reading data that belongs to another package. Is there something in this approach that ROS/bloom can adopt?
For full disclosure, we still generate omnibus workspace bundle assets, and that allows us to apply very broad rules (the release asset excludes all *.h, *.msg, *.py, etc). And to the extent that we’ve considered breaking that asset up, it would be to go to something more nix-y, where individual packages are identified by hashes rather version numbers.