Skip to content
Snippets Groups Projects
New issue look: Off

Speed up app building and publishing

    • Closed Issue created by username-removed-25246 @krt

    The Android ecosystem is moving fast, but we are a rather small team. Google and others are pushing out new (pre-release) dependencies, that most app developers are eager to use, even in release builds. Also Google moves to a "download everything at build" world order, which we might not be able to cope with. We cannot keep up with that speed, since we inspect those deps, get them merged into fdroidserver, require a single person to actually deploy to the buildserver etc. I am here to build a trusted ecosystem in my spare time, so I might be okay with lacking behind. However, most of our users, upstream app authors and some F-Droid devs (that need to "deliver"...) are not. Basically there are three issues to be addressed and I would like to hear other opinions on all of them.

    1. Manage dependencies on a per-app (or even per-build) base.

    I doubt there is much to discuss here. Most dependencies we used to manage in fdroidserver are logically bound to individual apps/builds. So it makes sense to manage them in the metadata. However, we need to agree on a way to do so. @eighthave suggested sudo apt-get install package in the build section, which I strongly object to. I really got pissed when Hans pushed some test changes to fdroiddata, not because I don’t like the changes, but because it is still not an agreed upon decision. Especially my talking points are:

    • No build should require super user permissions. Builds doing this, are broken.
    • Usingapt-get is tying us to Debian (based) distros.

    Both of these points are screwing with bare-metal builders, like me (or most likely upstream devs that do walk the extra mile and test building using fdroidserver). We talked a bit about the metadata only providing a list of dependencies (see https://gitlab.com/fdroid/fdroidserver/issues/317), that the server then translates into distro specific packages (which we only provide ourselves for debian), but in the end, there might be only one solution:

    • Make Debian mandatory
    • Make VM mandatory
    1. Don't whitelist maven repos, but check license of actual artifacts

    We currently put a great effort into making sure, non-free deps are not pulled in at all. Giving the fact that Google's non-free repo and Google's Support Repo are using the same license, Google setting up a new online repo (see https://gitlab.com/fdroid/fdroidserver/merge_requests/275) and app developers tend to use other thirdparty repos (e.g. hosted by the upstream developer on his github page), a whitelist approach might just not be working out in the future. Instead, we might go for a "allow everything, but check the license" policy. The linked MR provides a way to scan POm files for their license. The issues are:

    • Not all dependencies provide POMs.
    • We trust the license, not the code. (Currently we trust the repo, so this might in fact not be a problem, but an improvement)
    • Some devs dont populate license fields.

    My take would be: Be loose on repos, but strict on licenses. Nag upstream if necessary. Provide a list of used licenses (and also state where those are missing) in the build log (see https://gitlab.com/fdroid/fdroidserver/issues/319).

    1. Trust gradlew

    We currently have our own wrapper script that only uses already installed versions. Given that app developers are using pre-release versions of gradle quite heavily, we might need to trust their wrapper (if it downloads from gradle.org).

    Edited by username-removed-25246

    Designs

    Child items 0

    • No child items are currently open.

    Activity

    Please register or sign in to reply