Re:Why Postgres Extensions should be packaged and distribute...
by Vonng on Wednesday April 03, 2024 @11:42PM
(#39926313)
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.
Re:Why Postgres Extensions should be packaged and distribute...
by ahachete on Thursday April 04, 2024 @06:12AM
(#39928483)
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 ;)
Re:Why Postgres Extensions should be packaged and distribute...
by lrvick on Thursday April 04, 2024 @08:53AM
(#39929800)
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.
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:
Re:Why Postgres Extensions should be packaged and distribute...
by justinclift on Friday April 05, 2024 @08:57PM
(#39949035)
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. :)
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 ;)
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/...
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
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/0...
https://codeberg.org/stagex/stagex/src/branch/main/packages/...