PostgreSQL gives old APT packages a usable repository
The new PostgreSQL APT archive makes historical packages available through repository indexes. Package selection still depends on APT policy and the distribution being reconstructed.
Keeping old package files does not make them convenient to install. PostgreSQL's APT maintainers had collected packages since about April 2013 and exposed them through an informal directory in July 2016. Files for different distributions shared directories grouped by source package. The March 24 announcement of apt-archive.postgresql.org replaces that arrangement with an archive that APT can use directly.
The storage problem helped force the change. The announcement reports 175 GB for the archive, with 152 GB occupied by the old collection. Historical packages were consuming space on the main repository host while remaining awkward for users to navigate. The new repository gives those packages a separate home and the indexes expected by the package manager. That matters when the question is which package revision was available for a particular distribution.
I prefer PostgreSQL for relational systems, and packaging is part of what makes that preference practical. A database binary has to be obtainable in the environment where it will run. Preserving a version name in release notes is useful documentation, but an operator reconstructing an older installation also needs the corresponding packages and their dependency information.
A source entry identifies a distribution
The announcement specifies an archive suite with an additional suffix. Substituting an appropriate distribution name for DIST gives the following source entries:
deb https://apt-archive.postgresql.org/pub/repos/apt DIST-pgdg-archive main
deb-src https://apt-archive.postgresql.org/pub/repos/apt DIST-pgdg-archive main
These entries use APT's ordinary source-list format. The source-list manual in APT 1.8.2 describes separate files under /etc/apt/sources.list.d/ as well as the main source list. A file using the one-line format has a .list suffix. Each repository entry occupies one line and names its type, URI, suite and component.
The distinction between binary and source entries remains relevant. A deb entry describes binary packages, while deb-src makes source indexes available. Selecting a historical suite does not turn a binary package into its source package. That separation lets an investigation establish both what was installed and which source package accompanied it, without confusing the two kinds of repository metadata.
The suite is also part of the package's environment. An archive URL by itself does not specify the desired distribution. Keeping the source entry with a reproduction procedure makes that choice explicit, and avoids leaving the next reader to infer it from a filename or an installation date.
Inspect the versions APT can see
APT maintains a local view of repository metadata. The apt-cache manual describes querying that cache without changing installed package state. After repository metadata has been refreshed, the following commands expose package selection information:
apt-cache policy postgresql-12
apt-cache madison postgresql-12
The policy command reports detailed priority selection information for a named package. Without a package argument, it reports source priorities. The madison command lists available versions for architectures whose package lists APT has retrieved. Consequently, an inspection result describes the configured sources and local metadata, rather than every package that might exist somewhere on the server.
I find that distinction useful when assessing repeatability. A command transcript should establish what the package manager could select. A directory containing an old binary establishes less. Repository metadata makes the available alternatives visible through the same tools that participate in installation, which reduces the amount of manual reconstruction needed to explain a package choice.
Availability and selection are separate
Adding older versions does not imply that APT will select them automatically. The APT preferences manual describes priority rules followed by version comparison. Among versions with equal priority, APT generally selects the newest. Its ordinary policy also avoids downgrading unless an available version has a priority above 1000.
That behaviour makes the archive useful without making every archived revision an automatic replacement for an installed package. A maintainer can expose historical versions while leaving normal candidate selection to package policy. A reproduction procedure still needs to say which version is required and why. Merely adding a repository is an incomplete description of the intended installation.
The apt-get manual supplies the next distinction. Its update operation refreshes indexes from configured sources. Installation can select a specific version by appending an equals sign and that version to the package name. Dependencies remain part of installation, so choosing one PostgreSQL package version is not a complete specification of the operating system around it.
This is why the archive is most useful as an input to a recorded installation procedure. The procedure can name its distribution and package version, then inspect the candidate and dependency choices before installation. An archived package provides the historical artifact needed for that work. It does not, by itself, describe an entire machine or restore the database contents that machine once held.