-
Notifications
You must be signed in to change notification settings - Fork 459
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Availability on F-Droid #1
Comments
i don't mind the updates being available late on fdroid but please add it and thank you :) |
FYI: F-Droid now encourages reproducible builds, which mean that the developer's official binary is hosted by them, with them providing additional assurance that something didn't sneak in on the dev's side (by comparing the binary to a build they do). |
F-Droid does some patching (remove analytics and proprietary bits such as JUnrar or Google) which make binaries hosted on F-Droid differ from official ones. I'm pretty sure this would mean adding this patching to the push workflow. Basically, making 10 APK, 5 for the standard release and 5 other for a F-Droid flavor. Am I right? Would the project accept a pull request doing that? |
F-Droid does not, and can not, patch apps using reproducible builds, that's the whole point of them. |
The patching is more large than just Play Services.
You're saying that apps cannot be patched on both sides, only on GitHub side, is that correct? What's the technical limit that prevent F-Droid from patching when they sign APK themselves, but not when they generate a reproducible APK to compare with? Is it just not implemented yet? Unless you're saying that if Mihon maintainers offer a F-Droid flavor, they wouldn't be valid for F-Droid inclusion, because maintainers also make a standard flavor available for the same app with the same key? |
With reproducible builds, the application author's build is pushed to the repo, not the one F-Droid built. The F-Droid build is only used to verify that the official build matches the sources. This means F-Droid cannot modify the binary because they don't hold the key, which is the whole point of reproducible builds, since that means two sources verify it is actually built from the source code and not just one. |
I'll rather maintain one source of truth (GitHub). The Tachiyomi build wasn't officially maintained either. |
So if the "The F-Droid build that is only used to verify that the official build matches the sources" is patched at build time, and official build is also patched at build time, that makes both of them reproducible, that's what I'm not understanding |
Self-hosting an fdroid repo can be done by a github action. I used to run such an action myself, however I archived it because it stopped working due to (iirc) a package no longer being installed/installable via apt for the action. This is probably fixable somehow, I never actually investigated it. |
Was giving this a consideration again and 2 thing still keeps my answer a no
|
|
|
For most phones, it will be fine (as it was with Tachiyomi?), especially now that the min SDK is 26 which should limit to phones with bigger storage. If you believe it is an important matter, you can still add to the Fastlane description something like "For phones with limited storage, smaller individual split APKs are only available from the GitHub page". |
Describe your suggested feature
Would be nice to add this on F-droid like Tachiyomi or self-hosting an F-droid repo like Aniyomi
Other details
No response
Acknowledgements
The text was updated successfully, but these errors were encountered: