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
