08-12-2021, 08:15 AM
Consensus within the cat herd would be a novelty! I think the best you can hope for is to accommodate most of the wishes, but that may make the scope impractically wide, especially to start with. You probably need to start with narrower but more achievable goals, with aspirational goals for the future to be kept in mind so that you don't accidentally preclude them with a short sighted design decision.
I think I'd put distro-native packages in the aspirational part. The Open Build Service covers a wide range of distros at the moment, but even that doesn't cover Alpine/PmOS, or UBPorts. Then again for all I know it may be relatively easy to add new ones, and they just haven't yet felt the need to cover those. It also does AppImage so perhaps flatpak could be added too.
https://build.opensuse.org/
https://en.opensuse.org/openSUSE:Build_S...ld_targets
Flatpak at least gets you something relatively distro-agnostic, with the bonus of a degree of sandboxing. In principle it could cover the available linux-based distros without needing to do anything special for any of them, but I don't know if this is true in practice. The downsides include storage and memory inefficiency, and having to rebuild packages if any issues arise in included libs. How it deals with things like ModemManager vs. ofono, or gpsd vs. geoclue is another matter.
You'll probably need separate Free and non-free repos if you're not taking a free-software-only approach like F-droid. Some won't want to go anywhere near the non-free on principle, while others will regard at least some of it as necessary for the phone to be a daily driver. Depending on the approach to the build process for the free repo this could be a defining point for the relative security of the repos too.
There will be questions over the degree of vetting and curation. Quite apart from the notoriety of the Google Play Store, places like npm and pypi have had issues. F-droid's repeatable/verifiable builds may give some confidence that the provided binaries match the source release, but that doesn't address bad commits to the public source, or the 3rd party repackaging of closed binaries that we see on flathub. I'm not sure we have any great answers to this, but having a considered, published position on it would be a start. The F-droid tagging of potentially undesirable features is worth considering too.
I never really dealt with Maemo, but I got the impression the hardware abstraction was relatively consistent and well defined. We don't have that advantage. I've already mentioned the modem and location issues, but we have different backends for calendar, contacts etc. too, and probably more like audio mixer profile handling. If we're lucky these will be a consistent set of choices for major interfaces like Phosh, plasma-mobile and UBPorts, so we won't need per-distro guides for app examples too. We may need filters for app compatibility though.
I think I'd put distro-native packages in the aspirational part. The Open Build Service covers a wide range of distros at the moment, but even that doesn't cover Alpine/PmOS, or UBPorts. Then again for all I know it may be relatively easy to add new ones, and they just haven't yet felt the need to cover those. It also does AppImage so perhaps flatpak could be added too.
https://build.opensuse.org/
https://en.opensuse.org/openSUSE:Build_S...ld_targets
Flatpak at least gets you something relatively distro-agnostic, with the bonus of a degree of sandboxing. In principle it could cover the available linux-based distros without needing to do anything special for any of them, but I don't know if this is true in practice. The downsides include storage and memory inefficiency, and having to rebuild packages if any issues arise in included libs. How it deals with things like ModemManager vs. ofono, or gpsd vs. geoclue is another matter.
You'll probably need separate Free and non-free repos if you're not taking a free-software-only approach like F-droid. Some won't want to go anywhere near the non-free on principle, while others will regard at least some of it as necessary for the phone to be a daily driver. Depending on the approach to the build process for the free repo this could be a defining point for the relative security of the repos too.
There will be questions over the degree of vetting and curation. Quite apart from the notoriety of the Google Play Store, places like npm and pypi have had issues. F-droid's repeatable/verifiable builds may give some confidence that the provided binaries match the source release, but that doesn't address bad commits to the public source, or the 3rd party repackaging of closed binaries that we see on flathub. I'm not sure we have any great answers to this, but having a considered, published position on it would be a start. The F-droid tagging of potentially undesirable features is worth considering too.
I never really dealt with Maemo, but I got the impression the hardware abstraction was relatively consistent and well defined. We don't have that advantage. I've already mentioned the modem and location issues, but we have different backends for calendar, contacts etc. too, and probably more like audio mixer profile handling. If we're lucky these will be a consistent set of choices for major interfaces like Phosh, plasma-mobile and UBPorts, so we won't need per-distro guides for app examples too. We may need filters for app compatibility though.
