Philm has indicated that he is working on moving away from pacman on pinephone distros to make it more reliable. I have responded to him saying that i think this is ill-advised to fragment manjaro into different packaging systems, it’s like two distros under one name. I have also offered some high-level ideas how i think the goals could be arrived at in a better manner.
Now i have found a project that has actually gone ahead and done it, combining btrfs snapshots, read-only filesystem, atomic updates and parallel trees to boot into, allowing things like rollback and even running stable, testing and unstable branches in parallel, chosen at boot time, all based on arch and pacman
I do not like the immutable distro approach at all. In fact, it is one of the several things I do not like about Android. I want to be able to install the software I want, to upgrade or downgrade packages individually if needed, etc.
The astOS project you link to seems to actually implement some compromise, where whatever is deployed is still built on the user’s machine from packages, but in a snapshot that is deployed only if and after upgrading succeeded. Note that this still uses pacman, so I doubt that is what “moving away from pacman” would be referring to. As far as I can tell without having actually tried it, that approach sounds more flexible than centrally prebuilt “take it or leave it” images, but that flexibility comes at a performance and disk space cost that I doubt will be appreciated on the PinePhone. It also locks you into btrfs. The PinePhone images currently use ext4.
From my experience, the main reliability issue with upgrading the PinePhone is actually not pacman at all. It is the PackageKit pacman backend, which is awfully buggy. Upgrading with Discover has caused all sorts of breakage (see Discover system updates still very unreliable). If I use pacman directly from the CLI, it works much better. That is what urgently needs to be fixed to make upgrading work for average users who do not use a CLI (especially on a device with usually no physical keyboard). Replacing the whole pacman (and likely the whole concept of packages, because I doubt it would make sense to use, e.g., RPM or dpkg instead of pacman) is a sledgehammer approach that is likely to just introduce more problems.
So I found some time to analyze this app. More or less it uses BTRFS snap function, a tree structure and pacman cmds to update inside a btrfs-snapshot. If we compare the approach with our Live-ISOs, which uses squashfs it also has layers.
Our ISO installs the base root packages to the rootfs layer, then we add DE packages to the desktopfs layer, drivers to mhwdfs layer and the CAL installer to the livefs layer. There we have a base BTRFS rootfs, a desktopfs and maybe some other custom layers. rootfs is read only, desktopfs also but you can “clone” a layer and install packages to that. When happy you can “deploy” that to a layer, which gets mounted on next boot. There are options to update the snapshot layers and also the base layer. More or less a twisted docker approach.
On the Plasma-Mobile image for the Pinephone we use Discover and the packagekit backend which doesn’t work well via ALPM/Pacman. For the Phosh edition we ditched Gnome-Software, which also uses packagekit-backend and use Pamac, which is based on ALPM directly. That image is much easier and more stable with updates.
Having some similar approach like the Steam-Deck has might make sense, but you may lock the user to have some base packages and Desktop Environment pre-installed similar like Android has. Adding some Flatpak or other universal app approach on top makes it even more Android like.
Regarding the PackageKit backend, I doubt it will magically get fixed by PackageKit upstream. I think it will need somebody from Arch or from one of the derivative distributions (and that includes Manjaro) to maintain the ALPM/Pacman backend upstream (and unless this has recently changed, deal with Hughsie’s very strict code reviews; I remember having tried and failed to get an improvement to the hif backend (back when that was still a thing, it has been replaced with the dnf backend) into PackageKit: each time I had fixed all the issues he had pointed out in my pull request, he would come up with a new, even larger list of even harder to fix issues). PackageKit upstream basically considers the backends the job of the targeted distribution.