Re: RFC: Extension Packaging & Lookup

On Tue Oct 29, 2024 at 12:03 PM CDT, David E. Wheeler wrote:
> On Oct 29, 2024, at 12:51, Christoph Berg <myon(at)debian(dot)org> wrote:
>
>> I think this is where the whole idea of "provide binaries outside of
>> deb/rpm" is just going to die. You are trying to reinvent a wheel
>> that has been running well for decades, including lots of production
>> systems. I don't know anyone who would trust that new source of
>> binaries that doesn't integrate into their OS packaging system.
>
> That’s fine for Linux, but more challenging for macOS and Windows.
> It’s also an issue that the apt and yum repositories, while having
> a lot of stuff, don’t have all extensions.

Hey David,

I haven't worked on Linux packaging in a while, so take my input with
a grain of salt. Could we make distro packaging easier for extension
developers and take some of the load off of the packaging team?

I would imagine this workflow to be implemented as:

curl -X POST https://extensions.postgresql.org/package \
-H 'Content-Type: application/json' \
-d '{
"extension": "pgvector",
"tarball": "https://path.to.source.tarball",
"build-system": "meson",
"postgres-versions": [
14,
15,
16
],
}'

The backend would create the packages and publish them to the various
repositories. We would probably need to come up with a dependency
manifest that listed both build and runtime dependencies.

This would need some massaging, and has various caveats like require
using a well-known build system like PGXS or meson. There are probably
security implications that need to be worked through. The packaging team
could maybe have some burden lifted off their shoulders.

Is that something people would be interested in? As someone who writes
software, I largely find reaching the distribution channels is always
the hardest part.

--
Tristan Partin
Neon (https://neon.tech)