Linux package version comparison tool data: where the cross-distro version matrix lives

Comparing package versions across Linux distributions means answering one question many times over: which repository ships which release of the same upstream project, and which of those releases has fallen behind. Distro maintainers, packagers and platform teams all need the same raw material — cross-repository version and outdated-status records for thousands of projects at once — and building it by hand means tracking dozens of git tags, mailing lists and FTP trees.

Repology - Packaging Hub is the dataset built around exactly that problem. Its statistics page reports 324,959 known projects and 4,900,782 individual packages across 173 repositories, recorded at per-project-per-repository-per-package granularity, refreshed continuously, and snapshotted into dated PostgreSQL snapshots on a nightly cycle. Coverage reaches well past apt-and-rpm territory into BSD ports collections, macOS-oriented trees such as MacPorts and Homebrew, and Solaris-derived ecosystems.

One structural choice matters more than any single number: Repology keys its API by project name — curl, openssl, python — not by any distribution's local package name, because the point is to line up different naming schemes against one another. The most widely spread project observed during the August 2026 research pass was curl, present in 65 repository families and returning 805 individual package records from a single API call.

Two design decisions make these fields safe to build pipelines on. Datadory marks Repology's field definitions as verified rather than inferred, so downstream schemas can rely on them. And separating outdated (a genuinely older release than peers) from noscheme and incorrect (the comparator could not parse or order the version string at all) keeps real maintenance lag apart from version-string noise — a distinction naive scripts that simply sort semver strings never make.

Repository depth is uneven, and the ranking determines how much signal your comparisons carry:

1. nixpkgs unstable — 118,144 projects
2. AUR (Arch User Repository) — 92,744
3. Raspbian Testing — 45,840
4. FreeBSD Ports — 33,301
5. GNU Guix — 31,567

Below the top five, the tracked list spans Arch and BioArch, Debian and Ubuntu derivatives, Fedora including Terra, ALT Linux, Rosa, Gentoo with its GURU and LiGurOS overlays, Spack, Void Linux, Alpine, Slackware and SlackBuilds, OpenWrt, pkgsrc, Homebrew, Ravenports, CRUX, IzzyOnDroid, openmamba, T2 SDE, aerynOS, the Termux User Repository, Open VSX and PTXdist.

One counting caveat belongs in any analysis built on this data: Repology's statistics page lists 173 repository rows, while some third-party summaries describe the site as covering 300-plus repositories. Anchor any published figure to the statistics-page count, as Datadory's record does.

Two jobs dominate, and they pull in different directions. Targeted lookups need one project's full cross-repository row — every repository's record for curl, openssl or python, filterable by search term, maintainer, repository, newest, outdated or problematic, with separate per-repository and per-maintainer problem feeds alongside. Bulk work needs the opposite shape: the entire corpus as one relational snapshot, all 173 repositories keyed per project, so an upgrade queue can be cut with a plain status = 'outdated' filter instead of a walk through the whole matrix.

The consumption contract exists because traffic from misbehaving clients forced one on 23 April 2026: polite interactive rates for lookups, bulk clients pointed at snapshots once volume grows past what lookups suit, identifying clients required, and an explicit disclaimer that interface stability is not guaranteed and may change at any moment. That last clause is the practical argument for routing the feed through a delivery layer rather than coupling your pipeline to the wire format.

Through Datadory both shapes arrive the same way: typed rows with the field dictionary attached, delivered daily, weekly, or hourly — your call.

Repology answers "which distribution lags?". The registries themselves answer a different question — what is the canonical newest release, and in what order did releases appear — and three cataloged sources expose that ordering explicitly.

PyPI serves info.version per project across 877,215 projects, 9,420,495 releases and 20,805,417 files, attaching an OSV-derived vulnerabilities array with fixed_in versions to the latest-release response.

deps.dev bridges both questions: it resolves version lists across seven systems — GO, RUBYGEMS, NPM, CARGO, MAVEN, PYPI, NUGET — with publishedAt, isDefault, isDeprecated and deprecatedReason per version.

An outdated row alone does not tell you urgency. Three cataloged datasets convert the matrix into a ranked worklist:

Strong enough to build published numbers on. The anchor record scores 9 out of 10 on Datadory's quality rubric against a catalog-wide average of 7.81, with its field definitions marked verified rather than inferred — downstream schemas can rely on them.

The comparison layer does not travel alone. Alongside Repology's cross-repository matrix sit the canonical upstream orderers — crates.io, PyPI and deps.dev across seven language systems — plus OSV's 848,582 advisories across 38 ecosystems, NVD's ~381,418 CVE records with CPE applicability statements, and endoflife.date's 464-product lifecycle catalog. Version comparison, advisory linkage and EOL reality on adjacent rows is what turns an outdated flag into a decision.

Access-shape-wise the slice mirrors the wider catalog, where bulk delivery is the most common pattern (725 of 1,744 datasets, 41.6%, ahead of 574 official APIs), and a nightly PostgreSQL snapshot is exactly that pattern applied to version comparison. Through Datadory the whole stack arrives as typed rows with field dictionaries, sample rows and coverage statements attached, delivered daily, weekly, or hourly — your call.

Start with the Repology - Packaging Hub dataset profile, which carries the full field dictionary, the API terms summary and the verified dump path. The systems software data guide is the pillar mapping all 25 pooled systems-software datasets, showing where version matrices sit next to security feeds, platform telemetry and adoption benchmarks.