<div dir="auto">Hi Rinigus,<div dir="auto"><br></div><div dir="auto">I'm just an observer interested in Linux smartphone development, and far from a maps expert, but I wonder if there are choices here that are making the situation harder than it needs to be.</div><div dir="auto"><br></div><div dir="auto">Firstly, I'm surprised that the download API isn't just HTTP. If it was, I guess you could use any HTTP cache for offline support.</div><div dir="auto"><br></div><div dir="auto">Secondly, you seem to have tight coupling between map data format version and software library versions, requiring everyone to change in lockstep. Is that really necessary?</div><div dir="auto"><br></div><div dir="auto">Best wishes,</div><div dir="auto">     Neil</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 24 Aug 2019, 12:57 rinigus via Librem-5-dev, <<a href="mailto:librem-5-dev@lists.community.puri.sm">librem-5-dev@lists.community.puri.sm</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I would like to get an advice on how to package properly offline maps server - OSM Scout Server - for L5. Its a piece of software that allows such map clients as Pure Maps to work in offline mode (show maps, search locations, calculate routes, and other expected operations on maps). Its also written in a way that allows it to be used with other map clients - why not Gnome Maps, sports apps - and share the same data on device. The clients just have to use documented API for that. As a result, users don't need to download large offline datasets specific for some app, but can use the same datasets in multiple applications.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">What makes packaging situation a bit trickier is the fact that the server requires some specific libraries and their versions. These specific requirements are due to the used offline map data which has to match the libraries. We are going to be sharing the same datasets as used on Sailfish, L5, and Flathub-distributed version. So, all of the versions have to use the same libs versions. In addition, I should be able to update all of them within a reasonable amount of time when such updates are required allowing me to update offline datasets and libraries simultaneously (+/- 1-2 days) to ensure as good service as possible.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Due to the time constraints on updates and bundled libs, I think there is no point in going for full Debian packaging solution which would require packaging as a part of Debian. But I can surely make a special DEB for L5 and bundle all libs under it. Advantage of this solution would be ability to use systemd socket activation that is used currently to ensure seamless integration with map clients. In this case, maybe someone can tell where would I be expected to keep these bundled libs. On Sailfish, we were told to use /usr/share/appname/lib . Not sure its recommended on Debian-based distros.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Alternative would be to use Flatpak. Its by definition packages the libraries with it, I have already all scripts written and the server distributed via Flathub. In this case, I would need to add DBus activation (systemd socket activation is not supported), but that maybe a good idea anyway for covering requirements of desktop users. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I would prefer to package it as Flatpak, as it is expected to come to L5 and bundling of the libraries is not going against the common policies of that format. However, would that be expected to work on launch of L5? Server doesn't really require any fancy graphics as such - only has some Qt QML GUI for maps datasets management and few settings.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Thoughts regarding it?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Best wishes,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Rinigus</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div></div>
_______________________________________________<br>
Librem-5-dev mailing list<br>
<a href="mailto:Librem-5-dev@lists.community.puri.sm" target="_blank" rel="noreferrer">Librem-5-dev@lists.community.puri.sm</a><br>
<a href="https://lists.community.puri.sm/listinfo/librem-5-dev" rel="noreferrer noreferrer" target="_blank">https://lists.community.puri.sm/listinfo/librem-5-dev</a><br>
</blockquote></div>