3 ms·
Because Valve's target is deterministic (relatively, hardware revisions not-withstanding) pacman is actually perfect for their use-case. You can nail down a ne
by all2 5y ago
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. :)
- bpye 5y agoSurely Valve would be better served by having some immutable system partition and maybe even A/B image based updates?
- schmorptron 5y agoWe're about 2 years out from having that work with most packages though, aren't we?
- bpye 5y agoI'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.
- NGRhodes 5y agoValve (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.
- all2 5y agoYou're one step away from the venerable buildroot. You get deterministic builds of complete OSs from the Linux kernel up.