[meta:edit-log]: # "2020/06/03"
[meta:title]: # "Why ArchLinux not fit in Docker well"
[meta:keywords]: # "arch-linux, docker, package-manager"
[meta:description]: # "ArchLinux not fit well in a Docker image with the max utility package strategy and the rolling release."


To get fast update in Linux, it's not much option to choose from:
- use rolling release distro: Arch Linux
- use mini VM-like images: [Flatpak](https://flatpak.org), [Snap](https://snapcraft.io), [AppImage](https://appimage.org)
- use the source: `tarball, make, configure`

Since Arch Linux did this so well, you may want it in a box, a Docker box to be exact.
  But after some digging, turns out sadly it doesn't fill Docker that well.


## The reason ArchLinux Docker image is "huge"

The size of the [Arch Docker image](https://hub.docker.com/_/archlinux?tab=tags) is `122MB` compressed,
  quite big compared to [debian slim](https://hub.docker.com/_/debian?tab=tags)'s `26MB`

And after taking a [Dive](https://github.com/wagoodman/dive) into the image,
  some interesting thing is found:
  There are `/usr/lib/libgo.so.16.0.0` (53M),
  `/usr/lib/libgphobos.so.1.0.0`(32M),
  and `/usr/lib/libgfortran.so.5.0.0`(12M),
  all size uncompressed

The main code for using Go, D, and Fortran it here in the base Arch image,
  that's very cool, but why?

Checking the Arch package, they all under the package `gcc-libs`,
  which also provide the famous `libstdc++.so.6.0.28`,
  thus:
> Required By (502)

For Debian, it's a single package:
  https://packages.debian.org/buster/amd64/libstdc++6/filelist

Next compare:
  https://www.archlinux.org/packages/core/x86_64/bash/files/
  and:
  https://packages.debian.org/buster/amd64/bash/filelist

That's a lot more files!

And finally compare:
  https://www.archlinux.org/packages/core/x86_64/gzip/
with:
  https://packages.debian.org/buster/gzip

Not tagging `optional` field as aggressively to Arch package as Debian `suggest` makes `less` a direct dependency of `gzip`,
  kind of understandable but still weird.

So the Arch packing strategy is not minimal cross dependency,
  but max utility (sort like most `npm` package now).
On the bright side, there will be far less package,
  and a few package-install later you've got all hot dependencies,
  so the next package will likely not bring in anymore dependencies.


## Arch Rolling inside the Docker container sound not that good

Another thing about Arch is the [Rolling Release + Partial upgrades are unsupported](https://wiki.archlinux.org/index.php/System_maintenance#Partial_upgrades_are_unsupported),
  or the fast rising sea level of min package versions.

This makes the docker layer caching more difficult,
  since more file may get changed (updated) and more often.
So it's changing the base image regularly or keep on squashing.

In general, if the latest package is not your main concern,
  just go with Debian or Ubuntu for your Docker base image,
  the Arch philosophy fit poorly in this space.