Bug#905068: ITP: golang-github-canonicalltd-dqlite -- Distributed SQLite for Go applications

[Clément Hermann <nodens@nodens.org>]

Hey,

thanks for the quick response!

On 9/14/18 2:24 PM, Free Ekanayaka wrote:
> Hey there,
> 
> I do have the intention to submit the patches upstream, but since 1) the
> work is not fully complete 2) SQLite authors are *extremely*
> conservative when it comes to contributions, that won't happen any time
> soon.

Totally understand.

> Is there anything that prevents you from going with second option? You
> can grab:
> 
> https://github.com/CanonicalLtd/sqlite/releases/tag/version-3.24.0%2Breplication3
> 
> and package it as a new sqlite-replication library. It's fairly safe to
> have it Conflict and Replace the regular sqlite package, since the
> patches onlly add things, they don't modify behavior or change APIs.

That's good to know (the "add only")!

>From the top of my mind, it should be possible, but I need to recheck
the policy, see how other forks do it, and ask the current maintainer of
sqlite3 how they feel about it. Especially as I'm not so familiar with
shared library packaging ^^

I guess normally, it would involve providing a virtual package and
changing the original sqlite3 to do the same. At least that's how it's
done for Mysql/mariadb for instance, but here there is no server binary
in sqlite3, so the situation is a bit different.

If the implementation used a different name, that would allow to have
both installed. Of course, That involves patching the go bindings as
well, and it would have to change again once the patches to sqlite3 are
accepted upstream. If it can indeed take a long time, maybe it's worth it ?


Cheers,

-- 

nodens