Hello Florian, Florian Eckert <[email protected]> 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 _______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
