Figure out how to identify and install additional dependencies #40
Labels
building
Tools to compile, test, and install PGXN distributions
design
Designing the architecture, protocols, tools, and interfaces for PGXN v2
help wanted
Extra attention is needed
packaging
Milestone
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:
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.
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?
The text was updated successfully, but these errors were encountered: