Support installing multiple user interfaces
We currently use some special APKBUILD variables including _pmb_recommends
and _pmb_groups
to "configure" a postmarketOS installation. _pmb_recommends
declares a list of packages to be installed alongside the package being installed, it is currently only used for postmarketos-ui-*
packages to provide a sensible list of default software, e.g. for Phosh you're likely to also want lollypop
, evince
, etc...
This is necessary because apk is declerative, /etc/apk/world
defines the packages you want, if the default apps aren't in that list but are instead installed via a dependency then they would get removed if the user uninstalls the package that depended on them. It also prevents those apps from being uninstalled if they aren't desired.
Unlike Alpine, postmarketOS tries to offer a set of sensible defaults out of the box, APK doesn't include all the necessary components to do this, which means we need something out of band.
When discussing the potential to support being able to switch user interfaces, or have multiple installed at once, some issues with the current approach were made apparent. When a user installs an additional postmarketOS ui package, they don't get the recommended additional packages, and they don't get added to any additional groups (e.g. feedbackd).
To deal with this, let's rework this feature to be handled in the context of the installed rootfs rather than internally via pmbootstrap/pmaports. Lets have a standalone configuration to define arbitrary additional metadata for packages, this can be used to define "recommended" additional packages and groups that the default user must be added to. There are 3 ways we can implement this:
1. Flat files + helper
A file structure can be used with a folder per package, files ending in .pkgs
contain a list of recommended packages to be installed, files ending in .groups
contain a list of groups the user must be added to. A helper program serves as a wrapper for apk
, used only when switching user interfaces, it can invoke apk to install the new UI, then parse the files to install recommended packages, optionally uninstall previously recommended packages that no longer apply, do group changes, etc.
For any recommended lists that are common to multiple packages, symlinks can be used, although that isn't super clean.
2. Config file + helper
Like above, except that instead there is a config file to define lists of recommended packages and for which packages they apply to, e.g.:
[[recommended]]
pkgs = ["evince", "lollypop", "firefox"]
for = ["postmarketos-ui-gnome", "postmarketos-ui-phosh"]
[[recommended]]
pkgs = ["dolphin", "other-kde-pkg"]
for = ["postmarketos-ui-plasma-mobile"]
[[groups]]
feedbackd = ["postmarketos-base-ui-gnome"]
This makes it clear what's for what; a config.d
folder could be used to keep it easily parseable by humans.
In both cases, the configuration and helper program will be packaged in pmaports, with the latter format I think it might be reasonable to include the configuration files directly in pmaports, this would keep changes in sync better.
Neither of these are ideal, it may be useful to revisit support for recommended packages natively in APK, though that doesn't deal with groups.
Both solutions are fundamentally the same, the goal is to expose this information better to end-user devices to make it easy to switch UI on the fly. The question is on which format folks prefer. I'm leaning more towards the second one as I think it's a bit neater that way, it can be toml, yaml or whatever else.
I'm interested in having a go at implementing this once I'm done with uni stuff in about a month, so assigning to me.