fix(docker): Docker image build fails on Ubuntu 24.04 due to removed libapr1 package

[spbolton]

Problem Statement

The dotcms/dotcms-test Docker image build fails with exit code 100 when apt install is run in Stage 2 of the Dockerfile (dotCMS/src/main/docker/original/Dockerfile). The package libapr1 was removed from Ubuntu 24.04 Noble as part of the 64-bit time_t transition and replaced by libapr1t64. The build was previously passing due to Docker layer caching masking the issue — once the cache is cold (new CI runner, clean build), the error surfaces.

Platform: Docker build / CI
Affected file: dotCMS/src/main/docker/original/Dockerfile (Stage 2, FROM ubuntu:24.04)

Steps to Reproduce

1. Perform a clean Docker build (no cached layers) of the dotcms-core Maven module
2. Run: ./mvnw install -pl :dotcms-core -DskipTests
3. Observe the Docker build fail with:

The command '/bin/sh -c apt update && apt upgrade -y && apt install -y --no-install-recommends ... libapr1 ...' returned a non-zero code: 100

Acceptance Criteria

• libapr1 replaced with libapr1t64 in dotCMS/src/main/docker/original/Dockerfile
• Docker image builds successfully from a cold cache on Ubuntu 24.04
• No regression in container runtime behavior (Tomcat Native / APR still functional)

dotCMS Version

Latest from main branch

Severity

High - Major functionality broken

Links

NA

[github-actions]

PRs linked to this issue

• fix(docker): replace libapr1 with libapr1t64 for Ubuntu 24.04 compatibility by @spbolton

[spbolton]

Investigation findings — closing as misdiagnosis

After deeper investigation, the reported issue does not exist. Here is what was found.

libapr1 is not missing from Ubuntu 24.04

libapr1 is available on Ubuntu 24.04 as a virtual package alias — libapr1t64 declares Provides: libapr1:

$ apt-cache showpkg libapr1t64 | grep -A3 Provides
Provides:
1.7.2-3.1ubuntu0.1 - libapr1 (= 1.7.2-3.1ubuntu0.1)

Running apt install libapr1 on Ubuntu 24.04 succeeds — apt resolves it to libapr1t64 automatically. The package was never removed from the perspective of dependent package names.

The real cause of the observed local build hang

The local Docker build appeared stuck due to outbound port 80 being blocked at the network level. The ubuntu:24.04 Docker base image ships with HTTP apt sources:

URIs: http://ports.ubuntu.com/ubuntu-ports/

apt update would open HTTP connections that the router silently dropped. The process hung indefinitely with no error output, which was misread as a packaging failure.

Why CI/CD was unaffected

CI runners have unrestricted outbound HTTP. apt update completed normally, libapr1 resolved via the virtual package alias, and builds passed throughout. There was never a regression here.

[spbolton]

Closing — see investigation findings above.