Workflow for Managing Remote Repositories
This is the main ticket for dealing with remote repositories. Please feel free to create corresponding sub-tickets as required.
It is related to #36 (closed).
Pre-Installed Remote Repositories
At the moment, we plan on having two remote repositories pre-installed: F-Droid and Guardian Project. However, the user might want to remove them from their own list. The repositories would still be available for other users of the same instance.
Own Remote Repositories
Users should be able to add their own remote repositories.
- If they add a pre-installed repository that they had removed previously, it will be re-added to their list of remote repositories.
- If they add a remote repository unknown to the system, it should just be added to their list.
Adding Remote Repositories and Error Handling
Adding a remote repository takes time, because the entire index need to be downloaded and verified. So we might want to make this an asynchronous process. The adding process can also fail for various reasons. For example, the index signature can fail to verify (likely a permanent error) or the server is not reachable (might be a temporary error). It is also possible that remote repositories that had been added a long time ago, suddenly stop working (temporarily or permanently).
Therefore, we probably need some sort of a detail or status page/area for remote repositories that notifies the user about the current state of the remote repository (e.g. pending/added/had_error/disabled), when it was last updated and if there are any problems. This page could also give options for removing the remote repository and for re-activating the repository when it was disabled due to too many errors.
Maybe we also want to allow the user to change the URL in case it has changed. This could be a feature for later though and needs to be handled carefully, because users invisibly share remote repositories in the system.