Analysis: "apt files missing for PG18" — Packaging/Infrastructure Report

Nature of the Thread

This is not a pgsql-hackers technical development thread in the traditional sense. It is a single-message infrastructure/packaging bug report posted by a user (Lloyd Albin) observing that the PostgreSQL APT repository pool directory for the PG18 major version series is empty, while the corresponding directories for PG17 (stable) and PG19 (devel) are populated normally.

The report is better suited to the pgsql-pkg-debian list (maintained by Christoph Berg and the apt.postgresql.org team) than to pgsql-hackers, but it has landed here and warrants analysis of what the symptom implies.

The Observed Symptom

The reporter provides three directory listings from ftp.postgresql.org/pub/repos/apt/pool/:

1. /18/ — contains only a stale d/ subdirectory dated 26-Feb-2025, with no p/postgresql-18/ subtree and no .deb artifacts for the PG18 server packages, client libraries, or -dbgsym debug symbol packages.
2. /17/p/postgresql-17/ — fully populated, including recent 17.8 builds from 10-Feb-2026 and backfilled 17.6 artifacts from 25-Sep-2025. Multi-architecture coverage is visible (amd64, arm64, ppc64el).
3. /19/p/postgresql-19/ — populated with devel snapshots named 19~~devel-3~20260507.1415.gecb2508aaf9.pgdg+1_*.deb, freshly built the same day as the report (07-May-2026).

The 19~~devel-...gSHA naming convention is the standard apt.postgresql.org snapshot scheme for the development branch: double-tilde forces the version to sort before any real 19.0 release per Debian version-comparison rules, and the embedded git short-hash pins provenance.

Why This Is Architecturally Interesting

The asymmetry is the key diagnostic signal. In a healthy apt.postgresql.org pipeline, the directory layout is driven by the pg_buildext/dh_pgxs toolchain plus the per-major-version source packages (postgresql-17, postgresql-18, postgresql-19) maintained in the Debian packaging git at salsa.debian.org/postgresql/postgresql. Each supported major version has its own source package because Debian policy requires parallel-installable major versions with distinct SONAMEs and binary package names (postgresql-18, postgresql-client-18, libpq5 being the notable shared exception).

Given the date context (May 2026), PG18 would be a released stable branch (PG18.0 shipped ~September 2025, with 18.1, 18.2, etc. point releases expected through 2026). The expected state is therefore:

• /pool/18/p/postgresql-18/ populated with 18.0, 18.1, 18.2, … .deb files across all supported architectures and Debian/Ubuntu suites.
• The /18/ tree should look structurally identical to /17/.

Instead, /18/ contains only a d/ directory (likely postgresql-common debug packages or a postgresql-18-* contrib package whose source name starts with d, e.g. postgresql-18-debversion), frozen at Feb 2025 — before PG18 was even feature-frozen. This strongly suggests:

1. The postgresql-18 source package was never promoted from the "experimental"/snapshot pool to the release pool, OR
2. A pool-cleanup or reprepro/dak operation inadvertently removed the p/postgresql-18/ subtree, OR
3. A symlink/rsync mirror inconsistency between the build host (atalia.postgresql.org historically) and the public ftp.postgresql.org frontend.

The stale d/ timestamp (Feb 2025) is the clue: it predates PG18 branching. That directory likely contains a contrib package that was pushed early to the 18 pool as a placeholder and never touched since, while the main postgresql-18 source package artifacts are missing entirely.

Implications for Users

Users attempting apt-get install postgresql-18 on Debian/Ubuntu via apt.postgresql.org would fail at the Packages.gz/Release index level (since the binaries the indices reference would 404), OR — if the indices themselves are also missing the 18 entries — apt would report "Unable to locate package postgresql-18". This is a production-impacting distribution outage for the current stable major version, affecting:

• New installations on Debian/Ubuntu
• Upgrades from PG17 to PG18
• CI systems pinned to apt.postgresql.org
• Docker base images that layer on apt.postgresql.org (including the official postgres:18 image's Debian variants, which pull from this repo)

Likely Resolution Path

This report would be routed to Christoph Berg (myon@debian.org), the long-time maintainer of apt.postgresql.org and the Debian PostgreSQL packages. Resolution typically involves:

1. Re-running reprepro include operations for the missing .deb and .dsc files from the build archive.
2. Verifying the distributions config file in reprepro lists PG18 as a valid component for each suite (bookworm-pgdg, bullseye-pgdg, noble-pgdg, etc.).
3. Triggering a fresh binary build via pgapt if the source package itself is missing from the archive.
4. Forcing a mirror resync to ftp.postgresql.org.

Why This Belongs on pgsql-pkg-debian, Not pgsql-hackers

pgsql-hackers is for core server development — patches, design discussions, commitfest coordination. Infrastructure reports like this one get better and faster responses on pgsql-pkg-debian or by filing at https://redmine.postgresql.org/ against the sysadmin team. The single-message nature of this thread (no replies captured) suggests either the report was redirected privately or handled out-of-band.