@marguedas Answered your more specific questions. For the more generic final question.
Is it possible to create even smaller container sizes, though, than ros-core or ros-base, for the cases when someone just wants to use Docker to quickly run examples like talker/listener without having to download the big base images first? Or is ros-core already the bare minimum of what is needed? Thanks.
Overall I'm sure that it's possible to make our containers smaller with general technical improvements. However that's not likely to fundamentally change the tradeoff of grouping packages for general purpose installations. If you want a super stripped down image for just the talker example it can be much smaller. But if you then also want to run ros2 topic pub it could also be significantly stripped down to use a much smaller container, but it will be a different container than talker's container because they have non-overlapping depedencies. If you have a generic target like ros-core or ros-base you get the benefit that if you pull that one image, you have the necessary dependencies for both of those tools as well as many other common tools. But clearly the size of that image is going to be larger than just the dependencies for a specific component.
For a given application there are tradeoffs to be made as to how many tools you'll want versus how much space and bandwidth you have available. For the simplest case, if you only have a very limited amount of space for images, then you have to make a custom stripped down image. If you have an intermediate amount of space and bandwidth available you then have to make the tradeoff of do you want more small images or fewer more generic images to provide coverage of the different functions that you need in your system. And of course at the other end of the spectrum if you have unrestricted size and bandwidth you can just have one large bundle of everything that you want.
The public images that we host are focused on providing the more generic images that are useful for a larger number of people. With the large number of packages and combinatoric complexity of selecting specific ones and their dependencies we can't feasibly provide the precisely optimized images for each specific use case. And in that case I'd recommend looking at making the specific docker image which selects the specific debian packages that you want in your image. You can do that by forking the 32nd line of a 39 line Dockerfile used to create all our standard images.
