Because Valve's target is deterministic (relatively, hardware revisions not-withstanding) pacman is actually perfect for their use-case.
You can nail down a new release on your local hardware using a bash script that calls pacman against specific packages and specific package versions. Once your local dev works, push that to the update tool. Hopefully you caught all the bugs. :)
Surely Valve would be better served by having some immutable system partition and maybe even A/B image based updates?
Re:Valve Steam Deck
by schmorptron on Friday July 16, 2021 @11:37AM
(#27857390)
We're about 2 years out from having that work with most packages though, aren't we?
I'm not convinced packages need to care. Most config users care about on a SteamDeck is going to be Steam or game specific, so Valve are in a good position to put that on some mutable partition.
For the system data, which could be immutable, they could either take an A/B approach with two different partitions, or perhaps use either btrfs or ZFS to allow the new version to be applied over the old version as a 'diff' of the system partition. On a failed update, or to rollback for any other reason the system partition would simply be rolled back to the last snapshot.
Valve (as they did with Debian based previous versions of SteamOS) will maintain their own curated repository of packages, so they can control the versions of packages directly, no need to mess about forcing versions via pacman.
Pretty sure it won't. I bet it's going to use a self-made system upgrade facility and not rely directly on pacman either.
pacman is great for its intended use-cases, but it's not a package manager you want to use with no supervision of an experienced user. It may even silently leave a package in broken state just because the rootfs went full during the upgrade.
And at the very least, pretty sure they're not going to use actual Arch system repos but roll their own.