Adding a repository

This page explains how support for a new repository can be added to Repology.

1. Check data compatibility

There are a few requirements to the data so it's usable in Repology.

Repology works with any data source (it doesn't even have to be a repository, news sites and catalogues are possible too) which provides package/project names and versions. More fields would be useful, but are not required. Since the data is to be compared to other repositories and sources, it needs to be compatible.

Versions should follow upstream versioning scheme and allow easy extraction thereof. This means:

Names:

Repology has powerful name and version transformation, normalization and blacklisting rules, so it's easy to normalize or ignore a few individual items, or global features which follow a defined pattern. However if the only way to normalize a repository is to add a lot of individual rules for for substantial subset of packages (most common reason for this is indistinguishable modules, as explained above), such repository is not acceptable. We suggest to reconsider naming scheme (which would benefit the repository too by preventing package name conflicts and ambiguities), in this case.

2. Publish the data

Repository needs data on packages in some machine readable format.

Note that this does not include any form of executable scripts, so directly parsing bash recipes or Makefiles is not supported - if your repository is based on something like that you'll have to parse them on your infrastructure and provide ready to use dump.

Repology already supports a lot of formats, including ones used by well known package managers (such as apt and yum/dnf), and you may already have on of these, but it's still highly preferred to have a separate custom dump, as it would allow more exposing more data, updating and extending it independently from your package repository.

The preferred format is single file JSON because of its flexibility, simplicity, and wide support. The file may be compressed.

The schema is free-form - anything you find convenient which does the job of reflecting your repository structure well. We intentionally encourage you to publish data not specifically for Repology, but for any consumer which may be Repology, or some other website, project or tool, generic or dedicated to monitoring this specific repository. The presence of such dump may as well encourage new tools and projects in your own community.

You're free to include as much data as possible into the dump. Even if some fields are not used by Repology right now, they may be supported in future, or may be directly usable by other consumers.

Here's a list of fields Repology supports right now in addition to mandatory package name and version:

Here's an incomplete list of what could be supported in future:

Examples

A generic dump format may look like this:

[
    {
        "name": "nginx",
        "version": "1.15.5",
        "summary": "High performance web server and reverse proxy server",
        "maintainer": "somebody@somewhere.com",
        "license": "BSD-2-Clause",
        "download": "https://nginx.org/download/nginx-1.15.5.tar.gz",
        "homepage": "http://nginx.org/",
        "category": "www",
        <possibly more fields>
    },
    ...
]

You may want to provide some metadata on a whole repository, or list packages as a dictionary (assuming keys are unique). Use arrays for fields which may contain multiple values (do not list multiple values in a single string).

{
    "repository_name": "My cool repo",
    "num_packages": 12345,
    "last_update": "2018-11-02T10:20:30Z",
    "packages": {
        "nginx": {
            "version": "1.15.5",
            "summary": "High performance web server and reverse proxy server",
            "maintainers": ["somebody@somewhere.com", "somebody@other.com"],
            "licenses": {"and": ["BSD-2-Clause", "GPLv2+"]},
            "downloads": [
                "https://nginx.org/download/nginx-1.15.5.tar.gz",
                "https://my-own-mirror.org/nginx/download/nginx-1.15.5.tar.gz"
            ],
            "homepages": [
                "http://nginx.org/",
                "https://web.archive.org/web/20181102070459/http://nginx.org/"
            ],
            "categories": ["Servers/HTTP", "Proxy/HTTP", "Proxy/Generic", "Proxy/SMTP"],
            <possibly more fields>
        },
        ...
    }
}

A couple of ways of handling subpackages, package variants/flavors, or source/binary packages dichotomy:

[
    {
        "name": "nginx",
        "version": "1.15.5",
        "subpackages": [
            {
                "name": "nginx-dev"
                <more fields specific to subpackage>
            },
            {
                "name": "nginx-extras"
                <more fields specific to subpackage>
            }
        ],
        "maintainer": "somebody@somewhere.com",
        <more fields>
    },
    ...
]
[
    {
        "name": "nginx-dev",
        "version": "1.15.5",
        "base": "nginx",
        <more fields>
    },
    {
        "name": "nginx-extras",
        "version": "1.15.5",
        "base": "nginx",
        <more fields>
    },
    ...
]

The former is preferred, as it's more explicit, allows to publish information related to both source and binary packages without duplication.

3. Add support to repology

Easy way

Just file an issue on GitHub.

Hard way

If you feel adventurous, you may prepare a pull request yourself. In general, a new repository support would consist of 3 things: