4 ms·

Why Postgres Extensions should be packaged and distributed as OCI images

27 points by samaysharma 3y ago

ahachete 3y ago
Happy to see this in HN (thanks for submitting it!). OP here. AMA
Vonng 3y ago
Why not continue to use rpm/apt for building and packaging? You can reuse these packages in the Dockerfile and the image, but not the other way around.
- ahachete 3y ago
  Because of the little gains and large additional effort required in exchange. rpm/apt are quite involved to package and the tooling is (at least compared to OCI) limited. They would provide little advantage over OCI which works on any packaging system and even OS. They don't enjoy the ecosystem advantages of OCI, despite their age. In summary, it could be doable, but it would require much more additional effort than packaging in OCI first. But sure, since it can be done, maybe someone wants to take on it. I won't be down for the job myself ;)
lrvick 3y ago
Great timing. Just 2 weeks ago I produced what to my knowledge is the first full-source-bootstrapped, deterministic, and OCI-native PostgreSQL package. Built and signed by multiple people and entirely distro agnostic. You can even build with your pick of several OCI engines on several operating systems so maximally portable too. If extensions are packaged similarly it will sure make my life easier integrating them. If you are going to package with only one standard, OCI is the most portable and flexible choice today IMO. https://codeberg.org/stagex/stagex/src/branch/main/packages/postgresql/Containerfile https://codeberg.org/stagex/stagex/src/branch/main/packages/...
- justinclift 3y ago
  > ... PostgreSQL package. Is it able to automatically upgrade people from older PG versions? If not, the MIT licensed code from here might be worth looking through and grabbing ideas from? :) https://github.com/pgautoupgrade/docker-pgautoupgrade https://github.com/pgautoupgrade/docker-pgautoupgrade Specifically the scripting here is the bulk of it, the majority of the other stuff is just the existing docker entrypoint code from the official Docker PG container: https://github.com/pgautoupgrade/docker-pgautoupgrade/blob/0d00eb8188d4f5d65ba5cda0953cee6a73c71227/docker-entrypoint.sh#L362-L558 https://github.com/pgautoupgrade/docker-pgautoupgrade/blob/0...
- justinclift 3y ago
  Oh, you'll probably want to use "make install-world" rather than "make install". The "-world" version also includes many PG extensions when it runs, which is likely beneficial. :) https://codeberg.org/stagex/stagex/src/branch/main/packages/postgresql/Containerfile#L57 https://codeberg.org/stagex/stagex/src/branch/main/packages/...
  - lrvick 3y ago
    Good call. Will get that into the next release
zilti 3y ago
Repeat after me: Docker is not a package manager, and OCI not a package format.

27 points by samaysharma 3y ago

Happy to see this in HN (thanks for submitting it!). OP here. AMA

Why not continue to use rpm/apt for building and packaging? You can reuse these packages in the Dockerfile and the image, but not the other way around.

ahachete 3y ago
Because of the little gains and large additional effort required in exchange. rpm/apt are quite involved to package and the tooling is (at least compared to OCI) limited. They would provide little advantage over OCI which works on any packaging system and even OS. They don't enjoy the ecosystem advantages of OCI, despite their age. In summary, it could be doable, but it would require much more additional effort than packaging in OCI first. But sure, since it can be done, maybe someone wants to take on it. I won't be down for the job myself ;)

lrvick 3y ago

Great timing. Just 2 weeks ago I produced what to my knowledge is the first full-source-bootstrapped, deterministic, and OCI-native PostgreSQL package. Built and signed by multiple people and entirely distro agnostic. You can even build with your pick of several OCI engines on several operating systems so maximally portable too. If extensions are packaged similarly it will sure make my life easier integrating them. If you are going to package with only one standard, OCI is the most portable and flexible choice today IMO. https://codeberg.org/stagex/stagex/src/branch/main/packages/postgresql/Containerfile https://codeberg.org/stagex/stagex/src/branch/main/packages/...

justinclift 3y ago
> ... PostgreSQL package. Is it able to automatically upgrade people from older PG versions? If not, the MIT licensed code from here might be worth looking through and grabbing ideas from? :) https://github.com/pgautoupgrade/docker-pgautoupgrade https://github.com/pgautoupgrade/docker-pgautoupgrade Specifically the scripting here is the bulk of it, the majority of the other stuff is just the existing docker entrypoint code from the official Docker PG container: https://github.com/pgautoupgrade/docker-pgautoupgrade/blob/0d00eb8188d4f5d65ba5cda0953cee6a73c71227/docker-entrypoint.sh#L362-L558 https://github.com/pgautoupgrade/docker-pgautoupgrade/blob/0...
justinclift 3y ago
Oh, you'll probably want to use "make install-world" rather than "make install". The "-world" version also includes many PG extensions when it runs, which is likely beneficial. :) https://codeberg.org/stagex/stagex/src/branch/main/packages/postgresql/Containerfile#L57 https://codeberg.org/stagex/stagex/src/branch/main/packages/...
- lrvick 3y ago
  Good call. Will get that into the next release

zilti 3y ago

Repeat after me: Docker is not a package manager, and OCI not a package format.