Figure out how to identify and install additional dependencies

[theory]

Summary

Figure out how to map generic binary dependencies listed in META.spec to OS- and version-specific packages.

Background

The v2 meta spec requires that dependencies be specified as purls, for example:

{
  "configure": {
    "requires": { "pkg:cargo/cargo-pgrx": "==0.11.4" }
  },
  "test": {
    "requires": {
      "pkg:postgres/pg_regress": 0,
      "pkg:postgres/plpgsql": 0,
      "pkg:pgxn/pgtap": "1.1.0"
    }
  },
  "run": {
    "requires": {
      "pkg:postgres/plperl": 0,
      "pkg:pgxn/hostname": 0,
      "pkg:generic:curl": 0
    }
  }
}

The second part of the purl defines the source for a dependency. While we could specify that authors fill in third-party binary dependencies for specific platforms, few would bother to do so for more than a platform or two Furthermore, names often change, especially with updated OS versions, which means static dependencies could get out of date.

The spec therefore mandates that pkg:generic specifies dependencies usually installed via system packages. It is then up to our tooling to map values to actual packages on all supported platforms (at a minimum: Debian-based, RedHat-based, Homebrew-based, and Windows (Chocolatey?)-based. But it will need to grow in the future.

So how should we do so?

Wrinkles

Some issues to consider while working out a design for this challenge.

• How should names be canonicalized?
• How should we account for sub-packages, like foo-devel, which will vary by OS?

Potential Solutions

A list of a few potential solutions to research. Not exclusive; if you find something better, then great!

Repology

Is it possible to use the Repology API for this? Given a Repology-standardized package name, can one look up the appropriate package(s) to install? If not, could the proper values be looked up by searching a Repology Database Dump?

Customize

Given the limited number of Postgres extension in existence today, could we manually inventory all of their requirements and maintain our own mapping of canonical names to packages specific to a given system? For how many OSes and versions? How much effort will it be, really?