Availability on F-Droid

[sitiom]

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

• I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
• I have written a short but informative title.
• If this is an issue with an official extension, I should be opening an issue in the extensions repository.
• I have updated the app to version 0.15.3.
• I will fill out all of the requested information in this form.

[halshar]

i don't mind the updates being available late on fdroid but please add it and thank you :)

[JFronny]

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).
IIRC, not hosting official binaries was the reason F-Droid was not supported by Tachiyomi, but with this that is now essentially fixed.

[papjul]

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?

[JFronny]

F-Droid does not, and can not, patch apps using reproducible builds, that's the whole point of them.
It is, however, correct, that F-Droid only allows FOSS software, and that using proprietary dependencies would prevent adding it to the repository in the first place. I was not aware of Mihon using play services, but those would have to be removed from the binary here or replaced with FOSS alternatives to make it available on F-Droid.
At least that is what I gather from other cases of apps getting on F-Droid.

[papjul]

I was not aware of Mihon using play services, but those would have to be removed from the binary here or replaced with FOSS alternatives to make it available on F-Droid

The patching is more large than just Play Services.

F-Droid does not, and can not, patch apps using reproducible builds

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?

[JFronny]

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.

[AntsyLich]

I'll rather maintain one source of truth (GitHub). The Tachiyomi build wasn't officially maintained either.

[papjul]

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

[Efreak]

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.

[AntsyLich]

Was giving this a consideration again and 2 thing still keeps my answer a no

1. For split abis f-droid requires version codes to be different which in turn will mess up the in app migrations.
2. I see nothing about letting the apps keep their own in app updater which leads me to believe that it is not allowed. Given I want users to be up to date this is also a negative for me.

[papjul]

1. Tachiyomi had the same migration logic, so I believe F-Droid default repo delivered only the universal build, which is fine
2. Self-update is possible as long as your build is reproducible (which will ensure both F-Droid default repo and you uses the same signature)

[AntsyLich]

1. The universal apk is a whooping 50mb file. While small to many it's still a huge file,

[papjul]

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".