Open emersonknapp opened 10 months ago
Here's the dotfile for the apt
dependency tree for rosidl-core-runtime
where it seems like most of the tree is coming from ros-iron-rosidl-core-runtime.zip
IIRC correctly from the meeting this was discussed in, this is caused by packages not being separated into -dev
variants. That is every ROS package is assumed to have both stuff needed to build against it and run with it. Some people have custom scripts to do this separation: https://github.com/jspricke/ros-deb-builder-action 🧇
Bug report
This is to start a conversation about this hopefully - not sure exactly what the solution is right now.
I'm trying to create a "relatively minimal" installation of just a few ROS packages for use in a specific context where size/bandwidth is at a premium.
I start with the
ubuntu:jammy
base Docker image, which is ~78MB.I run the following script to get the ROS apt repositories available:
Which adds a little overhead, and bumps the size to 107MB.
Now, in that container, I go to
apt install ros-iron-builtin-interfaces
which givesIf I add
--no-install-recommends
, that is mitigated quite a bit toBut that still seems like quite a lot. The full list of packages (with no-recommends) is as follows:
Some key names in here that strike me as clearly not required for runtime use for this package (not a complete list):
cmake
google-mock
googletest
libjs-sphinxdoc
python3-numpy
ros-iron-ament-*
ros-iron-rosidl-adapter
ros-iron-rosidl-parser
ros-iron-rosidl-*
(exceptingruntime
andtypesupport
, those are probably necessary)So, I'm wondering how we could start approaching making these much less heavyweight by stripping all the build-time dependencies.
For a comparison of some other package providing some meaningful unit of functionality,
ros-iron-rosbag2-storage-mcap
only will pull in 6kB to this bare environment. Admittedly they're doing very different things, but I would expect the amount of generated code and dynamically loaded dependencies for a message package to be quite small too!Tangent: An additional question would be if it'd be possible to install "just the C++" for the messages, since the Python may not be used in a particular environment and brings pretty heavy dependencies.