Add support for multiple repos with conflicting apps/apks
Right now, if there are conflicts between repo indexes, the last one to modify the DB wins. This is not too good. We should:
- Add a way to order the repos in the repo screen by priority (like higher is more important)
- Modify the DB to identify apps by e.g. (appid, repoid) instead of just (appid)
- Modify the DB to identify apks by e.g. (appid, vercode, repoid) instead of just (appid, vercode)
The last two are just what comes to mind, but there may well be better ways to do it. Long story short, we want to have all the data and want the user to be able to see all the info and install the same version from multiple repos.
Activity
One thing I'm concerned about when implementing this is that it doesn't end up too complicated, which could end up causing more issues than it solves. I think that having the install priority based on the order that the repos were added makes sense and is easy to represent to the user.
I think we can solve the related issues using other data. Like for example, updates should automatically only come from APKs that are signed by the same signing key. Updates signed by a different key should be ignored.
The key to coming up with good solutions here is to come up with good descriptions of real world problems, then address those. The problem I see a lot is if someone has both f-droid.org and guardianproject.info repos enabled. Then there is warring Orbot updates. I think that issue would be solved by "ignore other signed APKs" idea above.
mentioned in issue #330 (closed)
For the record, I'm getting more interested in this now, because I broke it in a branch where I was trying to fix #324 (closed). In order to ensure that I don't break things before merging my changes, I've taken a step back and written a test for
masterso that I can ensure I haven't broken things too badly. However, I'm not sure what the test should be testing.Here is my test method, all I know is that regardless of the order in which repos are updated, the result should be the same. If this requires some sort of priority management (e.g. based on the order in the repo list) then so be it.
Things I know it should do with the current repo updater:
- All .apks from all repos should be linked to the relevant app, regardless of two repos providing the same version code.
The main problem I see is that:
- The last repo to update with a specific app will be the one that sets the description for that app.
There are many other issues to do with the UI, and @zoff99's idea is a good way towards fixing some of them. However the UI issues are not interesting for the purposes of this test, only the way things end up in the database.
-
There are now tests in F-Droid for the current multi repo support (where apks get clobbered by later repos that provide the same version apk). In the process of writing those tests, I in inadvertently wrote tests for the desired behaviour documented in this issue here. I've commented out those "correct" tests, in the hope that they can be uncommented out by the person working on this issue.
Milestone changed to 1.0
-
This is now being tracked in #511 (closed), with !375 (merged) being the final (albeit WIP) MR to support multiple repos properly. Note that #511 (closed) doesn't include a change to the UI in terms of being able to reorder the repositories. There is not much point right now, because the UI is about to be redone. Although it seems likely that there will not be many changes to the Manage Repos activity, lets wait and see. In the mean time, I think I will close this in favour of #511 (closed).
