this one example with YT collapse shows the big problem with F-Droid app delivery. And it seems to unable to haste this (currently). @team , care to change something with that?
Not sure what it shows, sad to see everyone talk about this like it’s F-Droid’s fault when: a closed source network service treats its users as hostiles changing APIs willy-nilly breaking 3-rd party apps.
Read that phrase again, and again, and again, and stop ranting about what F-Droid can do or doesn’t do.
Did the F-Droid build service break? No.
Did the F-Droid publishing service break? No.
Did the F-Droid APK download service break? No.
Did the F-Droid app submission break? No
Does the site at fault still work in a browser? Yes, USE THAT! PANIC END.
/PS: Merge requests to streamline the F-Droid workflow are welcomed here:
Let’s fight this people, let’s fix it! git clone !!!
Exactly, how many of these who are “affected” (allow me to roll eyes here) would start contributing to F-Droid? I guess rather none. Once the fixed version is in everybody continues with their lives, the next day it was all a dream. (Until next time, there’s always a next time when it comes to this situation)
To sum up, there are two main reasons why app sometimes take a long time to appear in the index:
The building process is slow because we use a new separate virtual machine for every APK
New apps or updates are not published until every build currently queued is complete
I understand it can be frustrating but there is nothing we maintainers can do to manually speed up an important app update.
Of course, if you have ideas on how to improve the building process, your help is welcome.
And app authors that want more control over updates can create their own F-Droid repository.
(Also, keep in mind that we tend to publish updates rather quickly compared to other package managers that build from source like Ubuntu for example.)
Debian updates their package index 3 times a day. It would be nice we could do that as well, but we’re not there (yet?).
Well there was a > 60 hour delay there (between update and deploy) on the weekend. So something did break? I don’t know. At least that’s what caused the annoying delay in building new things.
If the F-Droid is actually working as intended without any delays between any of the stages we are able to publish a new index ~ once a day. At that pace nobody is actually complaining.
Just because I have no idea how f-droid works, why is that? I have a hard time figuring out the rationale behind this choice.
Also IMHO apps building, in addition to fifo, should take into account some kind of priority e.g. (top to bottom): security upgrade, broken app upgrade, standard/new features upgrade. Every time an app is built, the builder should check what the next high priority app is in queue and needs to be built, if any. Just an opinion of an outsider, I don’t know if it’s feasible right now.
Generating the index takes a few hours (fdroid update has to gather all kind of metadata information from all the apps source repos). You can probably imagine why it’s done in batches .
Most of the builds get automatically added by checkupdates. There is no point in this process where a build entry can be marked as more critical as any other.
Also it would not help at all because the server would still build all pending builds and everything is gated by the index signing in the end… :-/
Generating the index takes a few hours (fdroid update has to gather all kind of metadata information from all the apps source repos). You can probably imagine why it’s done in batches
This is a very interesting and useful information. I’m sure there’s a bug hanging somewhere for it. Please someone share if not difficult: besides obvious “caching” improvement I got another idea to purpose.
I’m just a lowly user who enjoys F-Droid immensely… I appreciate the time all of you put into making all this work. I always read in awe. A big THANKS.
Guys, I understand your frustration about how slow F-Droid delivers updates. Let me explan why this happens. F-Droid cycle looks like this:
Check for updates. F-Droid downloads recent changes of 2365 apps and parses them to find new releases.
Build. For each new release F-Droid starts a VM and builds it from scratch. Usually there are dozens. Even the smallest utility needs 7 minutes to build, while each Fennec APK will take up to 5 hours.
Generate index. F-Droid gathers metadata from fdroiddata (2773 entries), apps source code (98 file trees) and APKs (19229 of them, each needs to be unzipped and parsed).
Sign APKs and index. Ciaran manually transfers APKs and the new index to an air-gapped system (it has no Internet connection to avoid signing keys leaks), signs them and brings signed files back.
Hopefully you now see why each stage takes many hours and the whole cycle takes days.