About

Repology is a service which tracks and compares package versions in more than 120 package repositories.

Purpose

• For package/port maintainers:
  • Discover new releases of software you maintain packages for
  • Find new projects to package
  • Get in touch with fellow maintainers to improve packages together
  • Keep package naming and versioning schemes in sync to other repos for your and your user's convenience
  • Fix problems detected by repology, such as broken links
• For software authors:
  • Keep track of where and how well your project is packaged
  • Keep in touch with your product package maintainers
• For users:
  • Discover new releases of software you use
  • Pick distribution most suitable for you, in terms of package quantity, freshness or stability
  • Keep in touch with maintainers of software you use

Current and past supported repositories

• Linux repositories: Adélie, aerynOS, AlmaLinux, Alpine, ALT, Antergos, Amazon Linux, antiX, AOSC, Apertis, Arch and AUR, Artix, Ataraxia, BlackArch, Calculate, Carbs, CentOS, Chakra, Chimera, CRUX, Debian, Deepin, Devuan, Distri, ELRepo, Endless OS, Entware-ng, EPEL, Exherbo, Fedora, Funtoo, Gentoo, glaucus, Guix, GoboLinux, Hyperbola, KaOS, KISS, Kwort, LEDE, LiGurOS, Linuxbrew, Maemo, Mageia, Manjaro, Mer Project, Mint, MX Linux, Nix, NOIR, openEuler, openKylin, openmamba, OpenMandriva, openSUSE, OpenWrt, Parabola, Pardus, Parrot, PCLinuxOS, Pisi, PLD Linux, PTXdist, PureOS, Raspbian, RebornOS, Rocky Linux, Rosa, Sabayon, Salix, Serpent OS, Siduction, SlackBuilds, Slackware, SliTaz, Software Collections, Solus, SparkyLinux, stal/IX, T2 SDE, Tails, Tin Can Linux, Trisquel, UBI, Ubuntu, Void, Vylen Linux, Whonix, yiffOS
• *BSD repositories: DragonFly DPorts, FreeBSD ports, MidnightBSD Mports, OpenBSD packages, pkgsrc, Ravenports
• Third party repositories: BioArch, Buildroot, Chromebrew, Deb Multimedia, Debian Janitor, Gentoo overlays, GetDeb/Playdeb, KDE neon, MPR, OpenPKG, openSUSE additional repositories, PackMan, pacstall, RPM Fusion, RPM Sphere, SageMath, Spack, Terra, UnitedRPMs, WakeMeOps, xrepo
• Other *nix repositories: AIX Open Source Packages, AIX Toolbox, HaikuPorts, Homebrew, HP-UX, IBM i, OpenIndiana, MacPorts, postmarketOS, Rudix, SerenityOS
• And non-*nix repositories: Baulk, Chocolatey, ConanCenter, Cygwin, F-Droid, just-install, MSYS2 (msys2, mingw), Npackd, OS4Depot, ReactOS rapps, Scoop, Termux, Vcpkg, winget, YACP
• Upstream module collections or programming language specific package managers: Buckaroo, CPAN, CRAN, crates.io, GNU ELPA, Hackage, LuaRocks, MELPA, OPAM, Open VSX, PyPI, RubyGems, Stackage
• F/OSS news sites: DistroWatch, freshcode.club, libregamewiki
• Other sources: Wikidata

How does it work?

First, repology fetches and parses available sources of data on packages. There is a built-in set of fetchers and parsers for many types of sources, such as text index files, git repositories, web pages and JSON API output.

After raw package data is obtained from all available sources, it is aggregated per upstream project. By default, package names are used to aggregate packages, and though it works fine for most cases, real world data contains inconsistencies, so first an elaborate ruleset is used to handle inconsistencies specially. For instance, rules allow merging packages with different names into a single project (for example, firefox, firefox-lts and firefox43 into a single firefox), or, instead, split packages with a same name into multiple project (for example, clementine may be either a player or window manager, which are unrelated projects).

Last, for each project versions are compared with a custom general algorithm, and each package is classified by its version.

• newest^#repos - newest known version. The number shows how many repository families have this version.
• devel - newest known devel (or unstable) version. There may be both devel and newest versions for a given package.
• unique - package is only present in a single repository family, there are no other sources to compare it against, so although it's the latest version known to repology, is not really reliable.
• outdated - outdated version which requires updating.
• legacy - outdated version when a newer version is present. This is assumed to be legacy version preserved for e.g. compatibility.
• rolling - package is fetched from always latest snapshot or VCS master/trunk, so it is always latest and is not a subject for comparison.
• noscheme - the project does not have official versioning scheme, so versions used in repositories which are basically random.
• incorrect - version is known to be incorrect (e.g. version not officially released yet, or lacking alpha/beta/rc qualifier).
• untrusted - this source is known to likely supply incorrect versions, so is ignored proactively.
• ignored - version is ignored and excluded from comparison for some other reason (e.g. snapshots).
• vulnerable▲ - version is potentially vulnerable as there are related CVEs.

Ruleset is also used to mark ignored and devel versions

Updates

The repository data and the website are updated hourly.

Development

Repology is developed on GitHub.

• Web application (the one you're currently browsing) code, issues and pull requests.
• Updater backend (responsible for fetching and processing package data) code, issues and pull requests.
• Ruleset code, issues and pull requests.

Junior tasks include proofreading English texts (README, html templates), finding more mismatched packages and adding name transformation rules for them.

Alternatives

Some alternatives to Repology, and related projects:

• pkgs.org - packages search for Linux and Unix
• release-monitoring.org - upstream release monitoring