Re: [Proposal] databases/sqlite3 - enable session extension

On Sat, Feb 22, 2025 at 06:10:08PM +0000, Stuart Henderson wrote:
> On 2025/02/22 18:46, Volker Schlecht wrote:
> > On 2025-02-22 15:25, Stuart Henderson wrote:
> > > > > > # XXX needs bumps every time :-
> > > > > > -SHARED_LIBS += sqlite3 37.30 # 8.6
> > > > > > +SHARED_LIBS += sqlite3 38.00 # 8.6
> > >
> > > Should be 38.0 not 38.00.
> >
> > That explains the problems with finding it, I suppose?
>
> I haven't tested, but I do think this is likely.

Yes it is the case, although the variety of failure modes is quite
unexpected.

> > > > To 37.31, at least the handful of builds in your list that I tested, works again.
> > > > I noticed that when updateing, libsqlite3.so.38.00 did not replace
> > > > libsqlite3.so.37.30, but libsqlite3.so.37.31 did.
> > >
> > > Updates keep a version around that's compatible with existing programs
> > > built against the old library version.
> > >
> > > 37.31 is supposed to be compatible with programs built against 37.30
> > > so no need to keep 37.30.
> >
> > So I guess, 37.31 would have been the right choice anyway... fingers crossed
> > that the bulk build goes through.
> >
> > Thanks for the explanations!
>
> Yes, I think so.

It is only a minor bump required. About half the packages built in the
last 5 hours without fallout. ~55 hours more for the remainder, although
at this point I don't expect to see a lot of fallout.

> The lib versions are a bit of a nuisance in this port. We bump them
> because of checks recommended in https://sqlite.org/c3ref/libversion.html
> which some downstram users do:
>
> "Cautious programmers might include assert() statements in their
> application to verify that values returned by these interfaces match
> the macros in the header, and thus ensure that the application is
> compiled with matching library and header files"
>
> https://sqlite.org/src/forumpost/5a3b44f510df8ded suggests that the ABI
> is generally compatible across sqlite v3:
>
> "Ideally, the soname stays stable for so long as a library retains a
> compatible ABI. In this project, the ABI has never(?), within the v3
> lifetime, introduced an incompatible ABI, and so its historical soname
> of libsqlite3.so.0 is still legitimate"
>
> but when someone makes that suggested check (e.g. as done by subversion),
> there is indeed an ABI compatibility change with *every* sqlite release.
>

Great.