[lxc-users] LXD for OpenWrt

[Free Ekanayaka]

Hello Florian,

Florian Eckert <fe at dev.tdt.de> writes:

> Hello Free,
>
> I'm working on packaging lxd for OpenWrt.

Great! I've been an OpenWrt user and still have a LinkSys wireless
router with it on, although I don't use it anymore these days.

> I started a pullrequest discussion and a also added a first proof of 
> concept makefile.
> https://github.com/openwrt/packages/pull/8466
>
> Apart from the fact that I have to package lxd with the toolchain for go 
> at OpenWrt, I have to compile dqlite and sqlite first.
>
> 1. A new dqlite library. With dqlite I don't see a problem for now to 
> get this packaged in OpenWrt.
>
> 2. A patched sqlite version from you/CanonicalLtd
>
> This results in the following questions to you
>
> 1. Because the sqlite library is a patched version I think I can not use 
> the already included OpenWrt version?
>     https://github.com/openwrt/packages/blob/master/libs/sqlite3/Makefile

Correct. You can't use vanilla upstream SQLite.

However, you can use that Makefile and possibly even the source tree if
you wish, provided that:

- You apply the patch needed by dqlite
- You add --enable-replication to ./configure flags

The patch with respect to the latest SQLite version is published here:

https://github.com/CanonicalLtd/sqlite/releases/latest

it's currently sqlite-3.27.2.diff is regularly updated once new SQLite
versions come out.

> 2. Why do you not merge your changes upstream?

In the medium term, I do plan to submit the changes upstream. However
SQLite developers are unbelievably conservatives when it comes to
merging code from external contributors:

"SQLite is not open-contribution. The project does not accept
patches. Only 27 individuals have ever contributed any code to SQLite,
and of those only 16 still have traces in the latest release. Only 3
developers have contributed non-comment changes within the previous five
years and 96.4% of the latest release code was written by just two
people. (The statistics in this paragraph were gathered on 2018-02-05.)"

So I'll wait until I'm absolutely certain that the patch won't need any
further modification, which is not the case right now.

> 3. Why does the master branch from your repositry follows the sqlite 
> upstream version?

Because it's a patch, not a fork, so we regularly pull from upstream.

>     It confuses me that the History is disorderd and so I do not know 
> what the changes you made are

SQLite uses a VCS called "fossil" wrote by its main author. There are
third parties providing automatic export to git of the official fossil
repository. The export used to work quite well, and I could use git
workflows like merge to keep the history clean. However, since a couple
of releases something was messed up, either upstream or by the
conversion tool, and the head of the git mirror was not anymore a
descendant of the latest release. So in order to avoid having to force a
push, I had to change strategy and essentially commit diffs by hand.

I don't think there's any way to avoid this, given that we don't want to
force push.

For packages, I recommend to forget about git, and always rely on the
.diff artifact, which you can version control yourself if you wish

> 4. Is this a fork?

No, it's patch.

> 3. What patches do I need on top of sqlite for lxd?

Just the .diff published above.

>    If so does this influence the sqlite so that other software who uses 
> this do not work anymore or have a runtime problem?

No, the patch adds behavior which is only triggered if you use certain
new APIs. There is zero semantic changes for other software.

Cheers,

Free