[FEATURE] Provide pre-compiled .deb packages (and optional Docker base images) for python:*-slim

[doronbl]

Problem Statement

Building amazon-efs-utils from source on minimal container images (e.g., python:3.12-slim, python:3.13-slim) requires installing a full native toolchain — Rust 1.70+, Cargo, Go 1.17+, CMake, GCC/G++, Perl, and OpenSSL development headers — just to produce a single .deb package. This creates three significant pain points:

• Prohibitively long cross-architecture builds — Compiling efs-utils for ARM64 via docker buildx (QEMU emulation on x86 hosts) takes ~2 hours, making CI/CD pipelines impractical.
• Complex, repetitive multi-stage Dockerfiles — Every team that needs to mount EFS or S3 Files inside a container must independently replicate the same heavyweight build stage (see example below), which is undifferentiated heavy lifting.
• Blocked serverless and managed-runtime adoption — Environments such as ECS Fargate, and Amazon Bedrock AgentCore Runtime do not provide host-level mount capabilities. Users must mount the file system from within the container itself, which requires efs-utils to be installed inside the container image. Without pre-compiled packages, this is a significant barrier to adoption.

Motivation — S3 Files and Agentic AI

With the launch of Amazon S3 Files (April 2026), efs-utils v3.0.0+ is now the required client for mounting S3 buckets as file systems (mount -t s3files). This dramatically expands the audience for efs-utils beyond traditional EFS use cases.

In particular, agentic AI workloads — agents that read, write, and collaborate through files (analytics, coding, document processing) — are a primary target for S3 Files. These agents typically run on serverless or managed container runtimes (Fargate, AgentCore Runtime) using lightweight Python-based images. Providing pre-compiled packages would remove the single largest friction point for this emerging class of workloads.

Proposed Solution

Publish pre-compiled .deb packages for each release, targeting:

• Architectures: amd64, arm64
• Debian base: Bookworm (Debian 12) and Trixie (Debian 13) — covering python:3.12-slim through python:3.13-slim

These could be distributed via:

• GitHub Release assets (.deb files per architecture/distro)
• An APT repository (ideal for apt-get install in Dockerfiles)
• Optional: pre-built Docker base images on Amazon ECR Public Gallery (e.g., public.ecr.aws/aws/efs-utils:3.0.1-slim-bookworm) that include efs-utils + nfs-common + stunnel4 ready to use

Current Workaround

Below is the multi-stage Dockerfile I currently use to build efs-utils for an AgentCore Runtime container. This is the complexity that every user must replicate today:

# ── Stage 1: Build amazon-efs-utils ───────────────────────────────────────────
# Use 3.12-slim for builder — its gcc/binutils versions work with the FIPS module.
FROM python:3.12-slim AS builder

ARG EFS_UTILS_VERSION=3.0.1
ARG GO_VERSION=1.22.4
ARG TARGETARCH

ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y --no-install-recommends \
    curl ca-certificates git make cmake gcc-12 g++-12 \
    perl pkg-config libssl-dev binutils gettext dpkg \
    && rm -rf /var/lib/apt/lists/* \
    && update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-12 100 \
    && update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-12 100 \
    && update-alternatives --install /usr/bin/cc cc /usr/bin/gcc-12 100

RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
ENV PATH="/root/.cargo/bin:${PATH}"

RUN curl -fsSL "https://go.dev/dl/go${GO_VERSION}.linux-${TARGETARCH}.tar.gz" \
    | tar -C /usr/local -xz
ENV PATH="/usr/local/go/bin:${PATH}"

RUN git clone --depth 1 --branch v${EFS_UTILS_VERSION} \
    https://github.com/aws/efs-utils.git /tmp/efs-utils
WORKDIR /tmp/efs-utils
RUN ./build-deb.sh

# ── Stage 2: Runtime ─────────────────────────────────────────────────────────
# Use 3.13-slim — matches Debian Trixie's system Python, so efs-utils mount
# helper and efs-proxy all find botocore without PYTHONPATH hacks.
FROM python:3.13-slim

ENV DEBIAN_FRONTEND=noninteractive

RUN apt-get update && apt-get install -y --no-install-recommends \
    nfs-common stunnel4 \
    && rm -rf /var/lib/apt/lists/*

COPY --from=builder /tmp/efs-utils/build/amazon-efs-utils*.deb /tmp/
RUN apt-get update \
    && apt-get install -y --no-install-recommends /tmp/amazon-efs-utils*.deb \
    && rm -f /tmp/amazon-efs-utils*.deb \
    && rm -rf /var/lib/apt/lists/*

# Install botocore via pip (into /usr/local/lib/python3.13/site-packages).
# The Debian system python at /usr/bin/python3 uses a different site-packages dir,
# so add a .pth file to make it see the Docker-installed packages.
RUN pip install --no-cache-dir botocore \
    && DOCKER_SITE=$(python3 -c "import site; print(site.getsitepackages()[0])") \
    && SYSTEM_SITE=$(/usr/bin/python3 -c "import site; print(site.getsitepackages()[0])") \
    && echo "$DOCKER_SITE" > "$SYSTEM_SITE/docker-packages.pth" \
    && /usr/bin/python3 -c "import botocore; print('system python botocore OK:', botocore.__version__)"

COPY requirements.txt /tmp/requirements.txt
RUN pip install --no-cache-dir -r /tmp/requirements.txt

RUN mkdir -p /mnt/s3files

COPY agent.py /agent.py
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

ENTRYPOINT ["/entrypoint.sh"]

And the corresponding entrypoint that mounts S3 Files at container startup:

#!/bin/bash
set -e
if [ -n "$S3_FILES_FS_ID" ]; then
  if mountpoint -q /mnt/s3files 2>/dev/null; then
    echo "==> /mnt/s3files already mounted"
  else
    echo "==> Starting EFS mount watchdog..."
    /usr/bin/amazon-efs-mount-watchdog &
    echo "==> Mounting S3 Files: ${S3_FILES_FS_ID} -> /mnt/s3files"
    mount -t s3files "${S3_FILES_FS_ID}:/" /mnt/s3files
    echo "==> Mount complete"
  fi
else
  echo "==> No S3_FILES_FS_ID set — skipping mount"
fi
exec uvicorn agent:app --host 0.0.0.0 --port 8080

Impact

Without pre-compiled packages	With pre-compiled packages
~2 hour ARM64 cross-compile build	apt-get install in seconds
~800 MB builder stage (Rust + Go + GCC)	Zero build dependencies
Every team replicates the same Dockerfile	Single RUN apt-get install or FROM base image
Blocks serverless/container adoption of S3 Files	Enables frictionless S3 Files + EFS in Fargate, AgentCore

Additional Context

• efs-utils v3.0.0 added S3 Files support — this is no longer just an EFS utility; it is the mount client for S3 Files as well.

• The supported distro matrix in the README already includes Ubuntu 20.04–24.04 (.deb), but no pre-compiled packages are published.

• The build-deb.sh script already produces a clean .deb — the CI/CD infrastructure to publish these artifacts per release should be straightforward.

• The efs-proxy component (Rust binary) is the primary reason the full toolchain is needed; pre-compiling it would eliminate the Rust/Go/CMake dependency entirely for end users.