Proposal: improvements for repository management

f-droid client is good enough for most of use cases. however, i see room to improve whenever i use f-droid. i will write these improvements time to time from now on.
maybe i’ll contribute to code too but it’s not clear yet. let see this proposal for now.

target beneficiaries of this proposal is users and third party app developers.

currently, f-droid client handles repositories by two states and these are “enabled” an “disabled”.
it’s fine but i think we can improve that by changing to “active”,"passive and “disabled”.

“active” state is basically same thing as current “enabled” state. active repositories provides a list of apps browsable/installable by user and updates for these apps.

“disabled” state is same as current “disabled”. disabled repositories provides nothing and just stay there until user change it’s state again or completely remove.

“passive” state is new state between these two. it doesn’t provide a list of apps but continues to provide updates for already installed applications from this repository.
that means user can add some third party repo as “active”, install whatever they want and change it’s state to “passive” for getting updates while not seeing any other apps from that repository.

i think this change will give user better control on third party repositories which user needs few apps from that repository and nothing else.
however, this isn’t end of my proposal. i have an idea for third party developers as well.

we can introduce a new meta-data for use of third party apps. if third party app implements this then f-droid client will automatically read their repository from their app and add the repository as “passive” repository.

for example:


f-droid can scan installed apps and add the microg repository as “passive” repository if microg puts this meta-data to application tag in their AndroidManifest.xml file.
user won’t see other microg apps in f-droid client but they can know when an update available the already installed apps from that repo.

interface details:

  • current repositories setting page must changed to tabbed view with three tabs representing “active”, “passive” and “disabled”.
  • text must be added to top of page on every tab to explain meaning of current selected tab.
  • repository entries must have small text telling user how many app installed from that repository ( can be implemented for all entries or just for the “passive” repositories )
    and must show user a list of installed apps from that repository when clicked.

implementation details:

  • f-droid client must track which repository is pre-installed( like ), user installed or installed by meta-data scanning.
  • “passive” repositories installed by meta-data scanning should be removed when all apps installed from that repo removed.
  • “passive” repositories installed by meta-data scanning promotes to “user installed” when their state changed to “active” by user.

request for comment:

  • is this meta-data declaration covers all possible repository urls?
  • is “org.fdroid.repository” good key for that meta-data declaration or it must changed to something else?
  • should meta-data scanning work on apps that installed from already added repositories? ( should apps that distributed on can add their own repo as well? )
  • should we delete “disabled” repositories that once was “passive” repository added by meta-data scanning but changed to “disabled” by user when all apps from that repo uninstalled?

that’s all. i hope i explained it well enough.

There’s work in progress for Repo management, try to use latest alpha builds and re-test when those land :wink:

i’m using 1.19.0-alpha1 but didn’t see any new thing except laggy input field while adding new repository. i’ll check again when they land.

however, is they are same or related with what i’m saying or totally different things?
i didn’t see anything related on client’s gitlab repo.
did i missed something or they are in different place?

Change how the client handles multiple repos (#442) · Issues · F-Droid / admin · GitLab and the linked Wiki document

yes, it’s my bad. i didn’t know admin repo used for this and didn’t checked. also i didn’t see wiki repo and only looked wiki from the section “plan → wiki” of gitlab ui which is empty.

anyway, that repository priority situation is bad but changes on #442 looks fine. my proposed improvements doesn’t conflict with them but i think i should wait until #442 implemented.

also, i’m curious about development process. probably problems mentioned in #442 exists from start of the project while issue is just 2 week old. is changes/improvements like this only implemented when someone funds the project which in this case is ffdw-dvd?

because i know some minor problems/issues still exists after months if not years.
ui misalignments ( search bar padding ), duplicated downloads ( app/cache and app/files ), nonexistant “delete after install” option for “keep cached apps” duration and others which i can’t remember right now. though i didn’t raise issues on gitlab but i remember i mentioned them in matrix room.

not ffwd, but Client maintenance sponsored by the Calyx Institute | F-Droid - Free and Open Source Android App Repository

And given the size scope it helps to have someone working to get it done, not only on free time

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.