(I'm not an Arch Linux user, just stumbled on this PR)

Don't know if nano and vi are really necessary in a base image? For reference, I created a gist with the packages installed in the debian:wheezy; https://gist.github.com/thaJeztah/2bead9762a7c9df6dee4

@thaJeztah Thanks for the gist! It's a good base for comparison. What can you do with iproute or sysvinit in a container? AFAIK, network interface management is done on the host and containers don't need an init system unless you run multiple services in the same container for which the supervisor is recommended.

Also, vi and nano may be good targets for removal, though interactive containers may rely on them. Let's wait for feedback from others.

So far the packages I stripped out fall into three categories. Packages that

• do not work in containers, e.g. linux kernel
• duplicate work already taken care by the docker daemon, e.g. managing resolv.conf, configuring network interface, handling pci and usb devices (I know this may be possible in a --privileged container, but using privileged containers are discoureged)
• provide functionality necessary only in application specific containers, e.g s-nail

What to include in a container is highly personal, so I tried to avoid imposing my personal preferences on the base image generation. For example I never used ftp or telnet in a container, but they are included in virtually every linux distribution by default. Users take them for granted and removing them may inconvenience some.

Obviously there is a fine line between what to strip out and what to include, and it is largely based on personal preference. What I want to achieve here, is to strip out packages that are widely believed to be unnecessary because they provide functionality that belongs to the host, highly application specific and/or not widely used.

though interactive containers may rely on them

In my personal opinion, a base image should be a 'clean slate'; Editors are really personal and in most cases not even necessary (most containers won't be interactive). If someone wants to have an editor inside the container, he/she should create a base image, containing those tools.

Tools like sed, curl, gz etc, are used in many Dockerfiles, often to modify default configuration files or to download and expand dependencies during build, so those are candidates to keep in.

But, agreed, I think some other people should have a look as well. As said, I personally don't use this feature, so I'm not the best person to ask for a use case.

I personally think the images should be clean as well and not include editors etc, but @tianon is the main deciding factor here

I'm definitely +1 on removing editors, etc. from base images, but sometimes upstream isn't as privy to that (see Ubuntu as an example).

awesome info - bookmarking for docs :)

Thanks guys! I updated the pull request to remove nano and vi (shaving off another 1.6 MB) and updated the OP to reflect the changes.

@tianon let me know if you want me to squash the commits into one before merging.

With the list of @tianon, those packages are being installed into the image:

bzip2
coreutils
diffutils
e2fsprogs
file
filesystem
findutils
gawk
gcc-libs
gettext
glibc
grep
gzip
inetutils
iputils
less
licenses
logrotate
pacman
perl
procps-ng
psmisc
sed
shadow
sysfsutils
tar
texinfo
util-linux
which

If we ignore the fact, that dockerfiles may depend on them, or they may be useful for most of the users, these packages could also be removed: diffutils, file, gettext, grep, inetutils, iputils, logrotate, psmisc, sysfsutils, tar, and which.

procps-ng has to be removed after the pacman keys were populated because procps-ng contains pkill. Removing this package also removes the systemd package.

locale-gen, which is called from the script requires sed.

When leaving procps-ng and sed in, my image is 285,4MB in size.

@tianon good point. Amended.

@dasJ so, in both Debian and Gentoo, there's an understanding in package metadata that packages in the base set are not required to be listed explicitly in dependencies of other packages -- is that true in Arch as well? ie, are packages allowed to assume that basic tools like pkill, sed, grep, etc are available without explicitly depending on them?

This PR as-is LGTM anyhow, but I think there's clearly room for further discussion about the exist list of packages to purge. 👍

@dasJ You left out bash from the list, but other than that it's correct.

"If we ignore the fact, that dockerfiles may depend on them, or they may be useful for most of the users..."

I think this is the perfect argument against removing those packages.

file, inetutils, iputils, procps-ng, ps-misc, sed, sysfsutils, tar, which provide binaries that are too essential to be removed. An image without them would barely work. It would be impossible to derive new images from such a base. Many shell scripts would fail as well.

I'm not sure about logrotate, diffutils and gettext.

PS.: The list of installed packages in the OP was not correct. I missed e2fsprogs and texinfo, and included iproute2. It should be fixed now.

LGTM

@tianon That is not true for Arch.

Packages list all run-time dependencies even if they are in base. For example device-mapper lists systemd, both of them are in base. And so does the docker package. I think that's because in Arch base is a suggestion rather than a requirement and users are encouraged to customise even by leaving out packages they don't need (e.g. jfsutils).

So removing packages suggested by @dasJ may not prevent anyone from installing and using packaged applications. But user written scripts, e.g. docker entrypoint and related, would most likely fail.

Note: There is a similar rule for packages built from source. They should not list compile time dependencies that are already in the base-devel group (packages required for building packages, e.g. make and gcc).

Ah cool, thanks for clarifying!