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@debian.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)