Skip to content

Properly support multiple repositories with the same app

Fixes #511 (closed).

Provides proper support for multiple repos in the database + updater (despite not being able to reorder them in the UI yet).

Info

Previously, each app had only one row in the app table. This caused problems when its metadata was updated, because it would get overriden if two repositories provided the same app. This change:

  • Creates a new package table which acts as the table that includes one row for each app (like the app table did previously)
  • Re-purposes the existing app table as an app_metadata table, where each package can have multiple rows (one for each repository that provides that package)

This results in some queries which are slightly more complex, but the overall performance should not change too much. In the long term, it should have a net positive impact on performance, because we no longer need to join between tables based on a package name. Now we almost exclusively use integer IDs to join between tables. There are also appropriate indexes which make the queries avoid full table scans in all cases I'm aware of.

I realise this is a big MR, but it is as small as I could make it without submitting half finished stuff which breaks master. I've done my best to merge smaller MRs before hand, but I was unable to identify anything else to pull out of this MR as a separate thing.

Migration

All app/apk metadata is dropped, and then the repos are asked to update themselves again next time F-Droid starts.

Additionally, existing repositories have their priority changed to something more meaningful. On current master, if you add two custom repositories in addition to the four default ones, you will get the following:

rowid address priority
1 https://f-droid.org/repo 10
2 https://f-droid.org/archive 20
3 https://guardianproject.info/fdroid/repo 10
4 https://guardianproject.info/fdroid/archive 20
5 http://10.0.0.6:8888/normal-repo/repo 10
6 http://10.0.0.6:8888/conflicting-repo/repo 10

Note how the priority defaults to 10 for each additional repository which is added. This MR should change the priorities so they look like so:

rowid address priority
1 https://f-droid.org/repo 1
2 https://f-droid.org/archive 2
3 https://guardianproject.info/fdroid/repo 3
4 https://guardianproject.info/fdroid/archive 4
5 http://10.0.0.6:8888/normal-repo/repo 5
6 http://10.0.0.6:8888/conflicting-repo/repo 6

Here is a snipped from the logcat from DBHelper during the migration:

Setting priority of repo https://f-droid.org/repo to 1
Setting priority of repo https://f-droid.org/archive to 2
Setting priority of repo https://guardianproject.info/fdroid/repo to 3
Setting priority of repo https://guardianproject.info/fdroid/archive to 4
Setting priority of repo http://10.0.0.6:8888/normal-repo/repo to 5
Setting priority of repo http://10.0.0.6:8888/conflicting-repo/repo to 6

All newly added repositories on this branch will get the next highest available priority.

Future work

One thing which is not yet supported fully: Suggested version code.

Two repositories can end up with the same exact .apk file. If that .apk is the "suggested version", then we should eliminate the idea of "suggested version code" and instead have a "suggested apk" (which implicitly includes the repository it comes from, so we choose the one with the better priority). Right now, we kind of assume that it doesn't matter which repo provides the suggested apk, as long as one of them has an .apk with th ecorect version code and signing key.

I guess it doesn't particularly matter from a security perspective, because a malicious repo wont be able to trick a user into installing an apk with a different signing key, but it would be good to iron this out.

Merge request reports