Skip to content

Draft: pmb: extend pmb_recommends syntax to allow installing from flatpaks

Pablo Correa Gomez requested to merge flatpak-pmb-recommends into master

And do so when requested. This is for now a PoC, lots of things missing. But good to get the discussion started.

Design decisions:

  • UIs opt-in, so this is only enabled when upstreams want it
  • If the UI opt-in, and the architecture is well-supported, then try to install apps with flatpak by default. We are doing this for the shake of upstream wishes, so it only makes sense to have a configuration that by default matches what upstream wants.
  • Possibly also add an heuristic that if --disk is provided, but has less than 16GB, we skip it.
  • Allow users to opt-out by adding:
    • A pmbootstrap config option together with a question
    • A pmbootstrap flag to install pmbootstrap install --flatpak=never
  • There's been a lengthy discussion on how to have the most sensible configuration by default for all the packages. The initial heuristic was to use deviceinfo_year, and discard flatpak on older devices. Unfortunately this can have terrible consequences with generic ports. The real problem there is that the year makes no sense in generic ports. But that's not something we are going to fix now. So in the lack of a better alternative, we'll keep flatpak by default and for bpo images:
    • Rely on default (enabled per UI), so the config does not have to be updated for all devices
    • Disable flatpak for devices where it doesn't make sense, and never build images with flatpak for those
    • For generic devices where one does not know, then we'll build two variants: a minimal one (to discuss if without flatpak or directly without recommends), and the regular one with the default config

TODOs:

  • Figure out a way for device maintainers to opt-out by default from flatpak (e.g: devices are too slow or have too little storage) Solved by considering the UI as the blocker.
  • Profile storage changes (this runs, but my install failed because alpine and one-kernel-policy). @TravMurav checked that a cold-start on a msm-8916 from a horrible SD card took double with flatpaks. O f couse in those devices it's much more noticeable than in modern ones.
  • Add an option to allow users to opt-out when building images manually
  • Decide whether omitting a repository is equivalent to flathub, or whether we should always be explicit
  • Try to optimize things a bit more
  • How to deal with remote names and urls? This is pretty inconvenient, for now I've hard-coded https://dl.flathub.org/repo/flathub.flatpakrepo to flathub. Maybe one option is to make this a config value?
  • Add tests
  • Seems like bwrap does not like chroots. I'm getting this: "bwrap: Can't find source path /sys/block: No such file or directory
    Warning: Failed to install org.freedesktop.Platform.openh264: While trying to apply extra data: apply_extra script failed, exit status 256". Seems to be coming from https://gitlab.com/freedesktop-sdk/openh264-extension/-/blob/master/files/openh264-apply-extra.c
Edited by Pablo Correa Gomez

Merge request reports