Subject: Re: RFC: Extension Packaging & Lookup

From: "Tristan Partin" <[email-masked]>
Date: Tue, 29 Oct 2024 17:40:06 +0000

On Tue Oct 29, 2024 at 12:03 PM CDT, David E. Wheeler wrote:
> On Oct 29, 2024, at 12:51, Christoph Berg <[email-masked]> 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)

---

From: "David E. Wheeler" <[email-masked]>
Date: Tue, 29 Oct 2024 13:47:33 -0400

On Oct 29, 2024, at 13:40, Tristan Partin <[email-masked]> wrote:

> 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.

Yes, I’m hoping to provide the infrastructure to enable a pattern like this as part of the PGXN v2 project. Some details from the Architecture doc[1].

However, I think this is a bit off-topic for this thread, where I’d like to try to account for issues to be addressed by the proposed extension directory structure and search path.

Best,

David

[1]: https://wiki.postgresql.org/wiki/PGXN_v2/Architecture#Packaging