Replace individual packages with F-droid store

[Popolechien]

Rather than try and update a random number of apps on an unknown schedule, could we not simply download the F-droid store and integrate it somehow to the imager service or as even a downloadable package?

See F-droid server or webdash

I've seen this implemented on the butter box, not sure what the actual output is: https://gitlab.com/likebutter/butterbox-rpi/-/blob/main/docs/en/README.md#premade-content-packs-and-content-pack-recipes

[rgaudin]

I can't find any ticket but I believe we've discussed this several time that we want some kind of automation for apps that come from F-droid as well as a better integration in imager-service.

Rather than try and update a random number of apps on an unknown schedule, could we not simply download the F-droid store and integrate it somehow to the imager service

No. F-droid is a platform, it's several components and the core of it is a builder because that's the point of F-droid: building from source.
Even if we replicated this, we'd still have to define a sync/refresh schedule.

What we want to do is reuse its medatadata (fdroiddata) and download the APKs instead. There are some technical questions around caching but beside time to implement it, was we need is to define requirements for how it would be integrated into imager-service and how it would be presented on the device.
We have no idea how large the whole thing is but it's probably reasonable to assume it's gonna be too large for most users. Do we want some kind of selections? Or individual packages browser/selection in IS?

[Popolechien]

Do we want some kind of selections? Or individual packages browser/selection in IS?

While there is value is providing curated selections, that's more downstream in the OS images. As far as the Imager goes, mirroring Fdroid's content is what we should be after (as we can not know nor decide in advance what it is that users need/want).

Edit: ok, maybe not the email, connectivity and internet categories I guess.