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
