[Librem-5-dev] applications using native debs

[rinigus]

Hi Jeremiah,

thanks for help!

If you build against embedded openGL you should be okay-ish. The various
> ARM graphic implementations are standardized so that graphics in general
> work pretty well.
>

I guess paranoia does come out of these messages - 'okay-ish' is not
exactly something like 'you'll be fine' :)

As for environment, flatpaks are built using Flathub platforms, as in
https://flathub.org/builds/#/builders/32/builds/3757 . In this respect, I
don't know details regarding the platform. But, if its all standardized, I
presume it shoul dbe OK.



> There is no question that flatpak won't do everything. I think your use
> case is one area where debs will always be used, e.g. daemons. But also
> libraries and other lower-level middleware and tooling will benefit from
> being a deb I believe.
>

Indeed, OSM Scout Server has a daemon mode and its used most of the time
for offline maps. Pure Maps, on the other hand, doesn't need to be deb as
such. Its started and used via GUI only. Pure Maps is also developed quite
fast these days and the faster I can publish it, the better it is.



> Decent amount of software is distributed via alternative channels, mainly
> via OpenRepos. Compared to the official store, its a proper wild west.
> There are no checks, developers get their personal repositories (think of
> it as PPAs), developers can upload whatever they wish (could be taken down
> for copyright reasons), and all seems to work on trust. And, in my
> experience, this presence of trust works quite well for Sailfish. Community
> is small and if you release a decent software you start to build up the
> trust as well.
>
>
> I think that model might not work so well for the L5. I think it should be
> a "trustless" system so that you don't need to have a requirement on anyone
> else for approval or control. Providing reproducible builds will go a long
> way to replacing the trust element because if you can build a byte-for-byte
> identical binary from source code, well you know that you can trust your
> supply chain.
>

It helps if you can trust the supply chain. Then there is only a small
question of trusting the original software - that it doesn't have any
backdoors written in, for example. In this respect, you will have to make
up your mind and trust the authors. And that's the part where some kind of
trust by users (or distribution) is needed.


As you can imagine, I would be happy to get something like OBS for L5. How
> to hook it with QA procedures, that's another story. In some respect,
> having a documented build (if used for open-sourced project), is a good
> start for QA as well.
>
>
> Having the source code and being able to build it are huge for QA. :-) If
> you were to provide a repo I'd be more than happy to help you build a deb
> that we can use on the L5.
>

I have started packaging of components and this work is all available at
Github:

For Pure Maps:

https://github.com/rinigus/deb-qmapboxgl
https://github.com/rinigus/deb-qml-module-mapboxmap
https://github.com/rinigus/deb-qml-module-nemo-dbus
https://github.com/rinigus/deb-qmlrunner

Whether to invest major time into DEB packaging of Pure Maps, that's an
open question. If we don't benefit much from having it running from DEB
when compared to Flatpak (either in terms of testing issues reported
separately or day-to-day use), then maybe we should look into that later.

For OSM Scout Server, I haven't made any DEB scripts yet. These would have
to cover

Valhalla (as packaged in https://github.com/rinigus/pkg-valhalla-lite)
Mapnik with my patch to support compact description of geometries in SQLite
(https://github.com/rinigus/pkg-mapnik)
Libpostal (https://github.com/rinigus/pkg-libpostal)
OSM Scout Server (https://github.com/rinigus/osmscout-server)

At SFOS, my OBS repo is mainly OSM Scout Server dependencies and
dependencies of dependencies (with exception of Mapbox GL also in the same
repo). It maybe of help to see if something is missing on Debian:
https://build.merproject.org/project/show/home:rinigus:maps . Out f these,
ZeroMQ is not used by Valhalla lite version, so those are not needed.

Assuming that we have access to Noto fonts on a system, these fonts don't
need to be packaged. They are used if raster tiles are requested from the
server. Pure Maps doesn't need it, but some other software may. For
example, Gnome Maps is using raster tiles (but has no link yet with OSM
Scout Server).

Now, a tricky part with OSM Scout Server would be to ensure that we have
the compatible versions of the backends on multiple platforms. Namely, I am
packaging the geo-databases and distributing them separately. Sometimes, we
have to make jumps in backend libs which are incompatible. Upcoming jump
will be in Valhalla, when I manage to get my hands on it. That means that I
have to package the geo-databases, test it with new code; distribute all
OSM Scout Server binaries for SFOS, L5, and Flathub Linux, and then switch
to the geo-databases on servers. In practice, SFOS and Flathub Linux works,
L5 - we have to figure pipeline for it. This pipeline should allow me to
upload new version when ready, but I guess that's a part which is covered
by the upcoming store.

As for packaging of the server, having the requirement of compatible libs,
means that I have to bundle the libraries of these critical components with
the server. I cannot rely on distribution making a change that would be set
by the server.

Cheers,

Rinigus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.community.puri.sm/pipermail/librem-5-dev/attachments/20190608/c91b9af6/attachment.html>