Can anyone help understand why the balenalib base images (for Beaglebone Green at least) are much larger than the base alpine images?
balena run balenalib/beaglebone-green-alpine:3.11: 60MB
balena run alpine:3.11: 4MB
I tried to use the plain
alpine:3.11 image as the parent FROM image in a Dockerfile and it resulted in an amd64 image, rather than ARM.
If I use
arm32v7/alpine:3.11 as the parent FROM image then the
apk add commands in the Dockerfile fail as follows:
[Info] Building for armv7hf/beaglebone-green [Info] Emulation is enabled [Debug] Found build tasks: [Debug] main: build [.] [Debug] Resolving services with [beaglebone-green|armv7hf] [Debug] Found project types: [Debug] main: Architecture-specific Dockerfile [Debug] Prepared tasks; building... [Build] Built 1 service in 0:01 [Build] main [=========> ] 47% Step 11/23: standard_init_linux.go:211: exec user process caused "no such file or directory" [Error] Build failed The command '/bin/sh -c apk add avahi avahi-tools' returned a non-zero code: 1 Error: The command '/bin/sh -c apk add avahi avahi-tools' returned a non-zero code: 1 at Stream.<anonymous> (/snapshot/versioned-source/node_modules/resin-docker-build/build/builder.js:181:23)
I guess the balenalib images would make most sense if they were not so large, does anyone know why they might be so large vs plain alpine images?
But failing that, is it possible to do
apk add (even if not
install_packages) in a non-balenalib image?