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.
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. Cheers Clément Hermann <nod...@nodens.org> writes: > Hi! > > > On Tue, 31 Jul 2018 14:00:12 -0400 =?UTF-8?Q?St=C3=A9phane_Graber?= > <stgra...@ubuntu.com> wrote: > >> On Tue, Jul 31, 2018 at 10:10 AM Free Ekanayaka <fr...@debian.org> wrote: >> > >> > Hey, >> > >> > I would think that Stéphane will want to backport these changes to the >> > 3.0.x series, as they improve performance considereably. It wouldn't be >> > a big change for the LXD code itself, since this is mostly "backend" >> > code. >> >> Yes, we will be backporting the switch to the new dqlite >> implementation in the 3.0.x branch, should be in 3.0.2. >> > > > And I see it's indeed the case. Thanks! > > > Now the only issue in Debian context is that dqlite depends on a patched > sqlite3... > > > It there any plan to upstream those patches ? Or at least treating that > as a proper fork, with a different name ? The former would be better. of > course, but the later could at least make sure we can package it > separately (with conflicts/provides dance)... And the later is a way to > wait until patches are approved upstream. > > > As I see LXD packaging in Ubuntu is now replaced by snaps [1], I guess > it's not really necessary for Canonical, but that would really help the > packaging effort in Debian and other distros. > > > [1] https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1788040 > > Cheers, > > > -- > > nodens