On Tue 19 Mar 2019 at 09:41 +0100, holger krekel wrote:
thanks for the writeup ... I'd like to look at
the "state of building
deltachat" from the outcome perspective.
Absolutely, I tried to write up what I think is the path with the
minimal amount of work to achieve a subset of the goals: android and
linux releases while not consciously sabotaging the other goals.
We have at least 5 different
user-visible downloads that we want to provide:
- Android (currently works with the caveats also discussed below)
installable via f-droid, gplay and as direct apk from github releases etc.
- iOS (currently works but build is done in a ios/mac specific way)
installable via testflight
- Linux (currently Desktop works with flathub, which requires several manual
steps at least on ubuntu -- what's keeping appimage's from working btw?)
Inside an appimage you have to craft your binary in such a way it relies
only on a very strict subset of system services. The tldr is there is
no tooling support for this, not even from appimage itself, and it is a
lot of hard work to get it right and very hard to notice you got it
wrong. OTOH flatpak does provide good tooling and guarantees that it
will work correctly, it works well with the existing ecosystems, so it's
just a much smaller and easier amount of work.
- OSX (works ASFAIK but is not signed so leads to
- Windows (does not work, some experimental deltachat-core building works)
It seems the biggest challenge remains a Windows download and having a
mostly-automated, improved way to produce the Android/iOS/Linux/OSX outcomes
that are already working.
One advantage of having dependencies inlined is that
we know which
deps/versions are contained in eg "Deltachat Desktop Linux 0.200",
even if they are outdated. Inlined deps also simplify it for devs to
get started with doing PRs.
Bundled dependencies surely could have these advantages. They're also a
lot more work to get right and come with a much higher maintenance
burden. We've wanted this for rather a long time now and no one has had
the time to step up and do all the required work. So I've been trying
to think of how to get to reliable, repeatable builds with the least
amount of work. For the long term I still think this is a fine idea to
pursue and will happily provide help if someone want to work on it.
(this scenario is basically covered by the last bullet point i wrote
about under android btw)
However, coming from a debian or system packager
perspective, i can totally
see how inlined dependencies are considered evil ;)
This wasn't a specific goal of my writeup. It just turns out that given
how the ecosystems have evolved over the last few decades that's the
easiest way to do things. (I have to add that's not what I thought I'd
be writing when I started the writeup. Again it's what I -currently-
think is the least amount of work to get to a reliable, repeatable
But I am afraid that if we prioritize doing things
"right" from the
sys-packaging perspective, the build process and steps get more complex,
and it might further delay getting the outcomes we want for users.
Also deps are indeed changing as we are starting to replace C with
Rust dependencies so in a couple of months the dependency tree
might look quite different -- is it really worth then to modularize
all the current C dependencies and make the build of
deltachat-core more flexible?
I hope by now I've managed to convey that's a misunderstanding. Mind
you, I can still be mistaken too and part of the reason to write this
down was to see if people spotted ways to get to our goals with less