A number of development packages currently being installed in the build image are actually for use-case that either do not make sense in a container context, or are not used during buildpack execution (ie: aren't needed by either the buildpack directly, or when the apps's dependencies are installed/built).
Many of these packages have been simply been copy-pasted from one new stack to the next, even though they are not actually needed in the image.
As such, the following have been removed from the build image:
libacl1-dev: Used for the management of POSIX Access Control Lists. Whilst many Linux system tools use libacl (including coreutils), app dependencies won't be typically linking against it, so we don't need the headers for it.
libapt-pkg-dev: Development files for APT's libapt-pkg and libapt-inst. Neither our buildpacks nor apps need to link against libapt since they use the apt CLI instead.
libaudit-dev: For Linux Audit, whose libaudit is used by things like the login command, but otherwise not typically needed for app dependencies to link against.
libcap-dev: For management of POSIX 1003.1e capabilities, an alternative to the superuser model of privilege under Linux. Not something needed for app dependencies to link against.
libkeyutils-dev: For the management of keys in the kernel. Not useful in a non-root container context.
libkmod-dev: For the management of Linux Kernel modules. Not useful in a non-root container context. Also, the libkmod lib is not present in the run image, so this wouldn't be usable at runtime anyway.
libpopt-dev: For parsing command line parameters. Whilst many Linux system tools use libpopt, app dependencies won't be typically linking against it, so we don't need the headers for it.
libreadline-dev: Provides functionality for entering text in interactive scenarios, and the management of terminal history. Whilst many tools/runtimes will use the library, application dependencies themselves won't typically link against it, so we don't need the headers for it in the build image. (See note below about compiling runtimes.)
libseccomp-dev: Provides a high level interface to Linux seccomp filter. Was added in #105 to support a demo of an internal project that has since been abandoned (see https://github.com/heroku/build-team/issues/83). IMO this demo use-case should instead have used the APT buildpack instead of requesting addition to the base image while experimenting.
libsemanage-dev: For SELinux policy manipulation. This is not something app dependencies typically ever need to link against.
libsystemd-dev: Development files for SystemD. Not typically needed in a container context, plus not something app dependencies typically ever need to link against. Also, the libsystemd0 lib is not present in the run image, so this wouldn't be usable at runtime anyway.
libudev-dev: For enumerating and introspecting local devices. Not useful in a container context.
Note: For use-cases like compiling Python/Ruby/PHP binaries for upload to S3, any required headers (such as libreadline-dev) that aren't also needed for application dependencies should instead be installed in the image being used to compile those binaries, rather than being included in the build image here (example).
A number of development packages currently being installed in the build image are actually for use-case that either do not make sense in a container context, or are not used during buildpack execution (ie: aren't needed by either the buildpack directly, or when the apps's dependencies are installed/built).
Many of these packages have been simply been copy-pasted from one new stack to the next, even though they are not actually needed in the image.
As such, the following have been removed from the build image:
libacl(includingcoreutils), app dependencies won't be typically linking against it, so we don't need the headers for it.libapt-pkgandlibapt-inst. Neither our buildpacks nor apps need to link againstlibaptsince they use theaptCLI instead.libauditis used by things like thelogincommand, but otherwise not typically needed for app dependencies to link against.libkmodlib is not present in the run image, so this wouldn't be usable at runtime anyway.libpopt, app dependencies won't be typically linking against it, so we don't need the headers for it.libsystemd0lib is not present in the run image, so this wouldn't be usable at runtime anyway.Note: For use-cases like compiling Python/Ruby/PHP binaries for upload to S3, any required headers (such as
libreadline-dev) that aren't also needed for application dependencies should instead be installed in the image being used to compile those binaries, rather than being included in the build image here (example).Towards #266. GUS-W-15159536.