Repology is a service which tracks and compares package versions in more than 120 package repositories.
- 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
- Linux repositories: Alpine, ALT, Antergos, AntiX, AOSC, Arch and AUR, Calculate, CentOS, CRUX, Debian, Deepin, Devuan, EPEL, Fedora, Funtoo, Gentoo, Guix, GoboLinux, KaOS, LEDE, Linuxbrew, Mageia, Manjaro, Mint, MX Linux, Nix, OpenMandriva, OpenSUSE, OpenWrt, Parabola, Parrot, PCLinuxOS, Rosa, Sabayon, SlackBuilds, SparkyLinux, Ubuntu
- *BSD repositories: DragonFly DPorts, FreeBSD ports, OpenBSD packages, pkgsrc, Ravenports
- Third party repositories: GetDeb/Playdeb, KDE neon, some Gentoo overlays, UnitedRPMs, RPM Fusion
- Other *nix repositories: Homebrew, OpenIndiana, MacPorts
- And non-*nix repositories: Chocolatey, F-Droid, HaikuPorts, MSYS2, Vcpkg, YACP
- Upstream module collections: CPAN, CRAN, crates.io, Hackage, PyPi, RubyGems
- F/OSS news sites: DistroWatch, freshcode.club, libregamewiki
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 inconsincies, so first an elaborate ruleset is used to handle inconsistencies specially. For instance, rules allow to merge 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 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.
- ignored - version is ignored and excluded from comparison. Fake or snapshot versions are marked like this, either way it's not possible to compared it with other versions in a meaningful way.
Ruleset is also used to mark ignored and devel versions
The repository data and the website are updated hourly.
Junior tasks include proofreading English texts (README, html templates), finding more mismatched packages and adding name transformation rules for them.