Summary
imgutil currently pins the moby split-module client and go-containerregistry at the versions landed in #299 / #301 (Dec 2025):
github.com/moby/moby/api v1.52.1-0.20251202205847
github.com/moby/moby/client v0.2.2-0.20251202205847
github.com/docker/cli v29.1.2+incompatible
github.com/google/go-containerregistry v0.20.6
These are still the pins on imgutil's main tip (latest commit 73856e68, Apr 15 2026). Meanwhile dependabot in pack is trying to move the consumer side ahead to:
moby/moby/api v1.55.0
moby/moby/client v0.5.0
go-containerregistry v0.21.7
Because pack's MVS-resolved moby/ggcr versions are compiled into imgutil too, forcing pack ahead of imgutil breaks acceptance.
Impact on pack
In buildpacks/pack#2645 (grouped dependabot bump), the bump fails acceptance in two places:
rebase/daemon/* → ERROR: rebase app image: could not find base layer in image — imgutil's daemon top-layer/RootFS detection (read through the moby client) fails against moby/moby/client v0.5.0 / api v1.55.0. The --publish (go-containerregistry) rebase path still passes.
manifest annotate → broken by go-containerregistry 0.21.5 → 0.21.7.
As a workaround we split only the safe deps into buildpacks/pack#2647 and are holding moby/moby + go-containerregistry on #2645 until imgutil catches up. This recurs every dependabot cycle, so it'd help to track the bump here.
Ask
Update imgutil to build against the newer moby split-module client (moby/moby/client v0.5.x / api v1.55.x) and go-containerregistry v0.21.x, fixing up the daemon layer/RootFS detection if the client API changed. Once imgutil ships against the new client, pack can take the held bumps.
References
Summary
imgutil currently pins the moby split-module client and go-containerregistry at the versions landed in #299 / #301 (Dec 2025):
github.com/moby/moby/apiv1.52.1-0.20251202205847github.com/moby/moby/clientv0.2.2-0.20251202205847github.com/docker/cliv29.1.2+incompatiblegithub.com/google/go-containerregistryv0.20.6These are still the pins on imgutil's
maintip (latest commit73856e68, Apr 15 2026). Meanwhile dependabot in pack is trying to move the consumer side ahead to:moby/moby/apiv1.55.0moby/moby/clientv0.5.0go-containerregistryv0.21.7Because pack's MVS-resolved moby/ggcr versions are compiled into imgutil too, forcing pack ahead of imgutil breaks acceptance.
Impact on pack
In buildpacks/pack#2645 (grouped dependabot bump), the bump fails acceptance in two places:
rebase/daemon/*→ERROR: rebase app image: could not find base layer in image— imgutil's daemon top-layer/RootFS detection (read through the moby client) fails againstmoby/moby/client v0.5.0/api v1.55.0. The--publish(go-containerregistry) rebase path still passes.manifest annotate→ broken bygo-containerregistry0.21.5 → 0.21.7.As a workaround we split only the safe deps into buildpacks/pack#2647 and are holding moby/moby + go-containerregistry on #2645 until imgutil catches up. This recurs every dependabot cycle, so it'd help to track the bump here.
Ask
Update imgutil to build against the newer moby split-module client (
moby/moby/client v0.5.x/api v1.55.x) andgo-containerregistry v0.21.x, fixing up the daemon layer/RootFS detection if the client API changed. Once imgutil ships against the new client, pack can take the held bumps.References