Hence the idea of targetting Noetic with this.
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.
1 Like
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.
1 Like
Just an update: many of the PRs submitted by @marguedas have been merged.
The most important one being
https://github.com/ros/rosdistro/pull/23624
2 Likes
Sorry for dredging up such and old thread…it was the first one I found. Feel free to point me in the right direction if this is the wrong place.
Anyway, I was wondering if anyone has figured out a “better” solution to this over the years. I’m currently trying to solve this problem too and it feels like my only option is to build everything from source and maintain my own set of debs. (I hadn’t considered making the ‘fake’ dependencies before now though…that’s an interesting idea but still sounds like a lot of work)
On the robot I don’t need or want the header files and all that i just want the minimum set of things.
Adding a -dev or -devel variant doesn’t really make sense because in my view that’s what the existing binaries are…renaming them would cause problems for lots of people.
Instead what if we introduced a -min variant that does not bring in any of the development dependencies? i guess bloom would need to be updated to create them and rosdep would need to be updated to reference the -min version when loading in exec_depends?
I guess this is a hard problem for ROS because of all the legacy stuff? But it’s also a big part of why “real developers” stick their nose up when you suggest using it. “It’s so bloated” is a common (and turns out justified) complaint.
We’re trying this out with the RHEL packages for ROS Lyrical! As you’ve identified, our model will be sort of inverted because our community expects the “default” package to fulfill the traditional “-dev” role. We’re using “-runtime” for the leaner subpackage.
For now, the runtime packages are empty, but just teasing apart the dependency tree we’re seeing the installation footprint reduced by roughly 30% for most runtime-only scenarios! It’s only going to get better now that we can actually realize the difference between exec_depend and build_export_depend.
We’re absolutely looking to expand this concept to the Ubuntu packages someday. Baby steps. 
3 Likes