Binary Repository #2
Created by: ollieparanoid
What won't work any time soon
Reproducible builds
The first binary repository approach involved reproducible builds, and it turned out not to be feasible and it wouldn't provide any real security benefit. Read https://github.com/postmarketOS/pmbootstrap/issues/64#issuecomment-334252443 for details. But we need a binary repository, it makes development much easier (compiling KDE takes forever, and we have some developers for whom compiling kernels also takes hours).
Please note, that I chose the reproducible build route to provide maximum security. We do not only run the binaries from this repository on the target devices (phones, tablets, ...), but also on the PCs where we develop (e.g. the cross-compilers gcc-armhf, ...), and sometimes even with root access (e.g. the heimdall flasher application).
What we have left from this approach and can use, are mirrors for hosting the packages (thanks to @MartijnBraam, see #365 (closed)).
Alpine building postmarketOS packages
So the next best thing would be, if Alpine built our packages along with the official packages. Then we wouldn't need to trust another person for providing the packages. Two Alpine developers had the idea of providing a PPA-like system at some point in the future, and therefore I've asked on the mailing list.
The short answer is, that they would need a new build system first, for which there is no time plan and that Alpine focuses on its upcoming 3.7 release so they don't have time for this.
Looks like we can talk about this again after 3.7, but realistically even if it worked out that way, it won't happen in the next few months, which means for me that we better have a short-term solution.
Short-term solution
It seems to me, that the fastest way to get this going is if I build all the packages myself, but not reproducible. This might be the next best deal regarding trust, because you need to sort-of trust me already for the pmbootstrap code, which also runs on your computer and while you can just read it, people rarely read all code before executing it.
I would use an i3 CPU with cross-compilation (which I'm using right now to do bigger builds), which is slower than what @PureTryOut uses. But then again, we use ccache and we only need to build changed packages. As long as the packages compile regularly, the delay shouldn't be more than one day or so, which is a lot better than what we have now (no binary packages).
For the first iteration, I would trigger the builds manually and I might be able to set this up in a week or so. I would write a script, that does the following:
- Clone
pmbootstrap - Build some (later all) packages
- Upload the whole packages folder to the official mirror
Future ideas:
- Delete outdated packages from the repo (use
zap -m) - GitHub trigger to build automatically whenever a commit lands in master
- compile natively on armhf/aarch64 (maybe on old quad-core phones? even the lg-mako has a quad core - compiling natively is better to avoid bugs from qemu)
- use a bigger machine for compiling if required
Thanks for reading. What does everybody think about this proposal?
@MartijnBraam: could you configure the primary mirror, so that packages can be uploaded via rsync or similar (right now we pull them from a git repository, but that isn't so great for binary files)? And as I understand it, the other mirror automatically syncs from the primary mirror, or how does it work?