From: Stuart Henderson <stu@spacehopper.org>
Subject: Re: import databases/duckdb
To: Rafael Sadowski <rafael@sizeofvoid.org>
Cc: Sebastien Marie <semarie@kapouay.eu.org>, ports@openbsd.org, dlg@openbsd.org
Date: Wed, 6 Aug 2025 09:15:15 +0100

i'm not a fan of the faked git version, can you drop that please?

"v${V}-0-g0123456789" -> "v${V}"

then it's ok sthen to import

pity about all the vendored versions of common libraries (zstd, snappy,
etc) but upstream doesn't seem to have a good way to use system
versions..

(btw the double extension in duckdb-1.3.2.tgz.gz is hard to read in
mutt+vim :)

On 2025/08/04 10:20, Rafael Sadowski wrote:
> On Sun Jun 02, 2024 at 03:59:30PM +0200, Sebastien Marie wrote:
> > Sebastien Marie <semarie@kapouay.eu.org> writes:
> > > 
> > > 3. split the port in several parts (maybe FLAVOR or separated ports):
> > >    - main part : duckdb executable + library without extensions (or
> > >      only minimal set)
> > >    - extension part : build the extensions and install *.duckdb_extension
> > >      files in a system directory
> > 
> > I started to explore build duckdb and extensions separately, but an
> > additional problem popup: extensions are checked for a signature (from
> > upstream key). So port build ones doesn't have signature and are, by
> > default, refused to be loaded (user should set `allow_unsigned_extensions`
> > flag to permit the load). From user point of vue, building extensions
> > separately seems to be no go.
> > 
> > So I intent to build most extensions statically (in cli and shared
> > library), and don't install static files.
> > 
> > Thanks.
> > -- 
> > Sebastien Marie
> > 
> 
> Please find attached duckdb-1.3.2. I cleanup a little bit and
> added do-test. I think there is no good solution for the
> extensions.
> 
> Rafael