[Librem-5-dev] applications using native debs

Fri Jun 7 11:24:17 PDT 2019

On Sat, 2019-05-25 at 00:21 +0300, rinigus via Librem-5-dev wrote:
> On Fri, May 24, 2019 at 10:44 PM David Boddie via Librem-5-dev <
> librem-5-dev at lists.community.puri.sm> wrote:
> > On Fri, 24 May 2019 20:57:11 +0300, rinigus wrote:
> > 
> > 
> > 
> > > while Flatpak would probably work for most of the applications,
> > we may need
> > 
> > > once in a while to build applications with DEBs for L5. Examples
> > include
> > 
> > > testing, distribution of applications that are not matching
> > Flatpak
> > 
> > > restrictions, and maybe some other reasons. Right now, I am
> > looking for it
> > 
> > > to be able to distribute maps software for testing and
> > distinguish issues
> > 
> > > coming from flatpak packaging - something I cannot rule out.
> > 
> > 
> > 
> > What kind of issues are you thinking of?
> 
> Its probably paranoia, but the thought is as follows. Flatpaks are
> build using some configuration settings - in my case at Flathub -
> that may not reflect fully hardware on which they run. In particular,
> I don't know how much of hardware-specific libs are used in such
> components like graphical stack (hw acceleration, for example). On
> PCs, we do have these nvidia flatpak packages, for example. On ARM, I
> don't know how much we do and how well L5 devkit is matched. But it
> maybe paranoia on my side induced by a lack of knowledge.

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. 
> As for other reasons for DEBs (daemons, probably some other cases),
> there are probably several cases where flatpak is just not the best
> way for approaching it.

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. 
>  
> > > I wonder whether we have any kind of build system that can be
> > used now for
> > 
> > > building "extra" deb packages that could run on L5/devkit? For
> > Sailfish, we
> > 
> > > have OBS that allows to compile complicated projects and
> > distribute them
> > 
> > > through its internal repositories.
> > 
> > 
> > 
> > I don't know much about the Sailfish ecosystem, though I have heard
> > of OBS.
> > 
> > What kind of QA procedure is in place around this distribution
> > system to
> > 
> > ensure that the packages that get built are trusted? Do they become
> > officially
> > 
> > "blessed" packages, or is it just a convenient way of running the
> > package
> > 
> > building process to make third party packages for unofficial
> > distribution or
> > 
> > sideloading, like Personal Package Archives (PPA) with Ubuntu?
> 
> Good questions and there are things to learn from SFOS. On my side, I
> know very little about PPA (from developer's side) and had to look up
> how it works for developers. But let me reply to the questions one by
> one.
> 
> On SFOS, there is an official store and packages in that store are
> blessed. The most of the restrictions are formulated via APIs that
> are allowed in the store. These APIs are checked for automatically
> when you upload your app. Next, app is checked manually by some
> officials in the store and only then released. What is done by that
> official and what is exactly is checked, I don't know. If something
> fails, you are told about it and you can resubmit new version. Such
> scheme works for closed- and open-sourced software and all work is
> done on compiled versions - whether by OBS or using SDK on PC.

In both cases I believe that Sailfish is using binary blobs and/or
proprietary code and build systems. At least that was the case when
Sailfish was Maemo. As Maemo's debmaster I remember well struggling to
get various build tools released which was very difficult. I think that
is still the case that Sailfish is not really open. OBS explicitly
allows this kind of thing.
> 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.
> Now OBS is very handy when you have to do something complicated and,
> in a way, it can be used to give some credibility to your packages
> and repositories. For mapping software, with large amount of
> components, its way easier to make your own repository and build the
> end-product that relies on some exotic libraries. In my case, its 
> https://build.merproject.org/project/show/home:rinigus:maps . If I
> change any of the packages, I can easily initiate rebuild as required
> to get the final result for different architectures and Sailfish
> versions. From PPA description, it seems to be similar to OBS. In
> practice, OBS is used by applications that are relatively
> complicated, by ports of SFOS to unofficial devices, and for
> extending / testing the core OS components. 
> 
> 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.
Cheers,
Jeremiah
> Sorry for long post.
> Cheers,
> Rinigus 
>  
> 
> _______________________________________________Librem-5-dev mailing 
> listLibrem-5-dev at lists.community.puri.sm
> https://lists.community.puri.sm/listinfo/librem-5-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.community.puri.sm/pipermail/librem-5-dev/attachments/20190607/58905f97/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part
URL: <http://lists.community.puri.sm/pipermail/librem-5-dev/attachments/20190607/58905f97/attachment.sig>