That is what I also read on main page. It is not clear will Firefox package require reboot to be applied.
BUT!
Than you read this in documentation:
abroot allows you to install kernel modules, drivers and other essential packages without compromising the filesystem’s immutability.
When a command gets executed in abroot, a transaction gets started in the transactional shell in the second root partition. If the transaction succeeds, the changes are applied using an overlay and synced with the current root on reboot. If the transaction fails, no changes are applied (due to a property known as atomicity). abroot also allows for on-demand transactions using the abroot shell command.
So Firefox is probably not a thing to switch A and B? But what happens if some package is successfully applied, B synced with A, after reboot it did not worked and you can not boot back.
Also both partitions will be minimum 20gb, that’s 40 allready. If you install 5gb package, it is successful, it will install 5gb package again… That’s double time! And No garantee the system will boot. Or it won’t be synced until it boots… Yet it could hang in 3 minuted after ram leak, and both A and B are synced, you will have 3 minutes to fix things after boot. Like uninstall that package. Instead of simple rollback.
The 40gb total are both already reserved, and a normal user isn’t supposed to modify it so it shouldn’t fill up.
For desktop apps, Vanilla will primarily stick to Flatpaks, so Firefox will also be a Flatpak.
VanillaOS already has a custom boot menu that can be used to switch slots in case an update went wrong, so that you can go back to your older, but working system.
The partitions are also not synced.
If you install something using abroot (e.g an update) it will only be installed to the unused slot.
So if you run abroot --update or use the included updater, and you’re in Slot A, it’ll modify Slot B, and vice versa.
That is what I also read on main page. It is not clear will Firefox package require reboot to be applied.
BUT!
Than you read this in documentation:
So Firefox is probably not a thing to switch A and B? But what happens if some package is successfully applied, B synced with A, after reboot it did not worked and you can not boot back.
Also both partitions will be minimum 20gb, that’s 40 allready. If you install 5gb package, it is successful, it will install 5gb package again… That’s double time! And No garantee the system will boot. Or it won’t be synced until it boots… Yet it could hang in 3 minuted after ram leak, and both A and B are synced, you will have 3 minutes to fix things after boot. Like uninstall that package. Instead of simple rollback.
IDK I do not get it.
The 40gb total are both already reserved, and a normal user isn’t supposed to modify it so it shouldn’t fill up.
For desktop apps, Vanilla will primarily stick to Flatpaks, so Firefox will also be a Flatpak.
VanillaOS already has a custom boot menu that can be used to switch slots in case an update went wrong, so that you can go back to your older, but working system.
The partitions are also not synced.
If you install something using abroot (e.g an update) it will only be installed to the unused slot. So if you run
abroot --updateor use the included updater, and you’re in Slot A, it’ll modify Slot B, and vice versa.Thanks, makes sense.