Bug#905068: ITP: golang-github-canonicalltd-dqlite -- Distributed SQLite for Go applications
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
Bug#905068: ITP: golang-github-canonicalltd-dqlite -- Distributed SQLite for Go applications
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 writes: > Hi! > > > On Tue, 31 Jul 2018 14:00:12 -0400 =?UTF-8?Q?St=C3=A9phane_Graber?= > wrote: > >> On Tue, Jul 31, 2018 at 10:10 AM Free Ekanayaka 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
Bug#905068: ITP: golang-github-canonicalltd-dqlite -- Distributed SQLite for Go applications
Hi! On Tue, 31 Jul 2018 14:00:12 -0400 =?UTF-8?Q?St=C3=A9phane_Graber?= wrote: > On Tue, Jul 31, 2018 at 10:10 AM Free Ekanayaka 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
Bug#905068: ITP: golang-github-canonicalltd-dqlite -- Distributed SQLite for Go applications
On Tue, Jul 31, 2018 at 10:10 AM Free Ekanayaka 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. > I'll Stéphane say the last workd tho. > > Thanks for the initiative, looking forward to see LXD in Debian! > > Free > > Clément Hermann writes: > > > Hi, > > > > On 31/07/2018 17:28, Free Ekanayaka wrote: > >> Hello Clement, > >> > >> dqlite upstream and LXD team member here. > >> > >> Please note that dqlite is going through a bit of change, which I > >> started to merge yesterday. So a few of the ITPs you have filed will no > >> longer make sense. > > > > Thanks a lot for the heads up! > > > >> In a nutshell: > >> > >> 1) https://github.com/CanonicalLtd/dqlite is now a C project > >> 2) https://github.com/CanonicalLtd/go-dqlite has Go bindings > >> 3) golang-github-canonicalltd-go-sqlite3 won't be necessary anymore > >> 4) golang-github-canonicalltd-go-grpc-sql won't be necessary anymore > >> > >> This will all be effective starting with LXD 3.4, to be released in 3 > >> weeks. > >> > >> In LXD master, this will be effective once we land: > >> > >> https://github.com/lxc/lxd/pull/4854 > >> > >> which should happen today or tomorrow at latest. > > > > Good to know! I guess this won't change anything for 3.0.x series ? > > That's what we're aiming for, since we want to package the LTS version: > > the users needing cutting-edge version should use the snap IMO. > > > > Cheers,
Bug#905068: ITP: golang-github-canonicalltd-dqlite -- Distributed SQLite for Go applications
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. I'll Stéphane say the last workd tho. Thanks for the initiative, looking forward to see LXD in Debian! Free Clément Hermann writes: > Hi, > > On 31/07/2018 17:28, Free Ekanayaka wrote: >> Hello Clement, >> >> dqlite upstream and LXD team member here. >> >> Please note that dqlite is going through a bit of change, which I >> started to merge yesterday. So a few of the ITPs you have filed will no >> longer make sense. > > Thanks a lot for the heads up! > >> In a nutshell: >> >> 1) https://github.com/CanonicalLtd/dqlite is now a C project >> 2) https://github.com/CanonicalLtd/go-dqlite has Go bindings >> 3) golang-github-canonicalltd-go-sqlite3 won't be necessary anymore >> 4) golang-github-canonicalltd-go-grpc-sql won't be necessary anymore >> >> This will all be effective starting with LXD 3.4, to be released in 3 >> weeks. >> >> In LXD master, this will be effective once we land: >> >> https://github.com/lxc/lxd/pull/4854 >> >> which should happen today or tomorrow at latest. > > Good to know! I guess this won't change anything for 3.0.x series ? > That's what we're aiming for, since we want to package the LTS version: > the users needing cutting-edge version should use the snap IMO. > > Cheers,
Bug#905068: ITP: golang-github-canonicalltd-dqlite -- Distributed SQLite for Go applications
Hi, On 31/07/2018 17:28, Free Ekanayaka wrote: > Hello Clement, > > dqlite upstream and LXD team member here. > > Please note that dqlite is going through a bit of change, which I > started to merge yesterday. So a few of the ITPs you have filed will no > longer make sense. Thanks a lot for the heads up! > In a nutshell: > > 1) https://github.com/CanonicalLtd/dqlite is now a C project > 2) https://github.com/CanonicalLtd/go-dqlite has Go bindings > 3) golang-github-canonicalltd-go-sqlite3 won't be necessary anymore > 4) golang-github-canonicalltd-go-grpc-sql won't be necessary anymore > > This will all be effective starting with LXD 3.4, to be released in 3 > weeks. > > In LXD master, this will be effective once we land: > > https://github.com/lxc/lxd/pull/4854 > > which should happen today or tomorrow at latest. Good to know! I guess this won't change anything for 3.0.x series ? That's what we're aiming for, since we want to package the LTS version: the users needing cutting-edge version should use the snap IMO. Cheers,
Bug#905068: ITP: golang-github-canonicalltd-dqlite -- Distributed SQLite for Go applications
Hello Clement, dqlite upstream and LXD team member here. Please note that dqlite is going through a bit of change, which I started to merge yesterday. So a few of the ITPs you have filed will no longer make sense. In a nutshell: 1) https://github.com/CanonicalLtd/dqlite is now a C project 2) https://github.com/CanonicalLtd/go-dqlite has Go bindings 3) golang-github-canonicalltd-go-sqlite3 won't be necessary anymore 4) golang-github-canonicalltd-go-grpc-sql won't be necessary anymore This will all be effective starting with LXD 3.4, to be released in 3 weeks. In LXD master, this will be effective once we land: https://github.com/lxc/lxd/pull/4854 which should happen today or tomorrow at latest. Cheers, Free "Clement Hermann" writes: > Package: wnpp > Severity: wishlist > Owner: Clement Hermann > > * Package name: golang-github-canonicalltd-dqlite > Version : 0.0~git20180507.e5bc052-1 > Upstream Author : Canonical Ltd > * URL : https://github.com/CanonicalLtd/dqlite > * License : Apache-2.0 > Programming Lang: Go > Description : Distributed SQLite for Go applications > > dqlite can be used to replicate a SQLite database across a cluster, > using the Raft algorithm. > - No external processes needed: dqlite is just a Go library, you link >it to your application exactly like you would with SQLite. > - Full support for transactions > - No need for statements to be deterministic (e.g. you can use time()) > > This is a dependency of LXD 3 (ITP: #768973) and will be maintained under the > Go team umbrella.
Bug#905068: ITP: golang-github-canonicalltd-dqlite -- Distributed SQLite for Go applications
Package: wnpp Severity: wishlist Owner: Clement Hermann * Package name: golang-github-canonicalltd-dqlite Version : 0.0~git20180507.e5bc052-1 Upstream Author : Canonical Ltd * URL : https://github.com/CanonicalLtd/dqlite * License : Apache-2.0 Programming Lang: Go Description : Distributed SQLite for Go applications dqlite can be used to replicate a SQLite database across a cluster, using the Raft algorithm. - No external processes needed: dqlite is just a Go library, you link it to your application exactly like you would with SQLite. - Full support for transactions - No need for statements to be deterministic (e.g. you can use time()) This is a dependency of LXD 3 (ITP: #768973) and will be maintained under the Go team umbrella.
