# Revision history [back]

Is there an option to apt-get remove afterwards as a Docker image won't usually need the -dev variants?

No, there is no option for that (in rosdep at least), but package manifests should split out their dependencies in exec and build dependencies. If they do that properly, you could automate removing the build dependencies. Unfortunately this would also depend on the rosdep db containing separate keys for devel and runtime dependencies, which isn't always the case.

I would guess there isn't an automatic way to do this, but if I could find the logic I could cobble something together for my own needs.

You might be interested in taking a slightly different approach, seeing as you're already using Docker.

See the Hermetic Robot Deployment Using Multi-Stage Dockers presentation from ROSCon'18: video (slides).

When running rosdep install on a clean machine it pulls down lots of packages from apt-get or whatever is installed. As far as I can determine, it is something connected with the package.xml, but sometimes a <depend>foo</depend> ends up installing libfoo-dev.

Is there an option to apt-get remove afterwards as a Docker image won't usually need the -dev variants?

No, there is no option for that (in rosdep at least), but package manifests should split out their dependencies in exec and build dependencies. If they do that properly, you could automate removing the build dependencies. Unfortunately this would also depend on the rosdep db containing separate keys for devel and runtime dependencies, which isn't always the case.

I would guess there isn't an automatic way to do this, but if I could find the logic I could cobble something together for my own needs.

You might be interested in taking a slightly different approach, seeing as you're already using Docker.

See the Hermetic Robot Deployment Using Multi-Stage Dockers presentation from ROSCon'18: video (slides).

When running rosdep install on a clean machine it pulls down lots of packages from apt-get or whatever is installed. As far as I can determine, it is something connected with the package.xml, but sometimes a <depend>foo</depend> ends up installing libfoo-dev.

Is there an option to apt-get remove afterwards as a Docker image won't usually need the -dev variants?

No, there is no option for that (in rosdep at least), but package manifests should split out their dependencies in exec and build dependencies. If they do that properly, you could automate removing the build dependencies. Unfortunately this would also depend on the rosdep db containing separate keys for devel and runtime dependencies, which isn't always the case.case (and in addition on all platforms that you'd like to deploy to to actually split dependencies such that they are different for build and run phases, which isn't always the case either).

I would guess there isn't an automatic way to do this, but if I could find the logic I could cobble something together for my own needs.

You might be interested in taking a slightly different approach, seeing as you're already using Docker.

See the Hermetic Robot Deployment Using Multi-Stage Dockers presentation from ROSCon'18: video (slides).

When running rosdep install on a clean machine it pulls down lots of packages from apt-get or whatever is installed. As far as I can determine, it is something connected with the package.xml, but sometimes a <depend>foo</depend> ends up installing libfoo-dev.

Is there an option to apt-get remove afterwards as a Docker image won't usually need the -dev variants?
No, there is no option for that (in rosdep at least), but package manifests should split out their dependencies in exec and build dependencies. If they do that properly, you could automate removing the build dependencies. Unfortunately this would also depend on the rosdep db containing separate keys for devel and runtime dependencies, which isn't always the case (and in addition on all platforms that you'd like to deploy to to, to actually split dependencies such that they are different for build and run phases, which isn't always the case either).